NBA Champion last year, leaves league for China with no coverage on ESPN? - <AUTHOR> https://sports.yahoo.com/nba-star-jeremy-lin-heads-china-110257711--nba.html <comment><AUTHOR> This has been one of the more interesting storlines to follow in the NBA for me. Carmelo's blackball may be crazier, but after catching wind of this development on social, I went to ESPN.com and couldn't find a single word written about this.

Any other similar reactions?

</comment><comment><AUTHOR> And before anyone else jumps down my throat...An hour later ESPN did post [https://es.pn/2Ua6iP7](https://es.pn/2Ua6iP7)

It's still interesting</comment>


Unix History Repository - <AUTHOR> https://github.com/dspinellis/unix-history-repo <comment><AUTHOR> Paper describing the processes of recovering historical versions, attribution, and creation of the repo: [https://www.dmst.aueb.gr/dds/pubs/jrnl/2016-EMPSE- unix-histo...](https://www.dmst.aueb.gr/dds/pubs/jrnl/2016-EMPSE-unix- history/html/unix-history.pdf)

If you only look at the GitHub repository, look at the branch listing.

(I'm not the author, just an admirer of the work.)

</comment><comment><USER2> "Latest commit by ken almost 47 years ago"

Ken Thompson, I suppose...</comment>


Tools for remote work - <AUTHOR> Hi,
I was wondering what tools you can recommend for remote work in a software company?
Things that make it easy to (in real-time) have discussions around product, architecture, code (pair programming), virtual whiteboards, etc? <comment><USER2> For pair programming you might try using Screenhero. Or screenshare using Skype or whatever IM tool you use (lag can be an issue if you have a slow network connection)

</comment><comment><USER3> This product blows me away

[https://zoom.us/](https://zoom.us/)</comment>


IPhone Application Marketing: What Every Developer Needs to Know - <AUTHOR> http://www.positivespaceblog.com/archives/iphone-application-marketing-what-every-developer-needs-to-know/

<comment><USER2> Not bad points to take on board, but they're generic, and suited to product marketing in general - not specific to iPhone application marketing, alas.</comment>


Petition: Reduce the term of copyrights to a maximum of 56 years - <AUTHOR> https://wwws.whitehouse.gov/petitions/!/petition/reduce-term-copyrights-maximum-56-years/MnXrd3xG <comment><USER2> Is this petition a joke? If we're going to try to change the copyright laws, let's bring the term back to how much it was originally: 14 years. Owning an idea for 50 years is just too much. You don't need 50 years to recover your costs on one single work.</comment>


Walmart scammed into selling PS4 for $90 - <AUTHOR> http://www.cnbc.com/id/102197050

<comment><USER2> I've seen fine print of lowest-price-guarantee that rules out any online offers. In one case the shop told us to add the shipping cost to the one offer we presented (shipping cost was zero so we got the deal).</comment>


High-Speed Trading Isn't About Efficiency—It's About Cheating - <AUTHOR> http://www.theatlantic.com/business/archive/2014/02/high-speed-trading-isnt-about-efficiency-its-about-cheating/283677/ <comment><USER2> A few immediate thoughts:

Transaction volume is ultimately not the important metric--revenue is. And, following [1], it seems that the total revenue for HFT was probably around $2Billion in 2013--for a whole industry, that's not very much! Measuring transaction volume is akin to comparing shipping between Amazon and Walmart ignoring the fact that Amazon ships directly to consumers while Walmart mostly ships to large Walmart stores.

"...increasing liquidity is the last refuge of bullshitters" is not an argument--it's an assertion. That was not really supported. Liquidity _is_ a good thing; the article claims that HFT does not help much because most of the actual benefits happened before its advance. Of course, considering how limited HFT revenue is compared to other forms of trading, it's likely that the benefits are just smaller in proportion.

So I don't see, from the article, that HFT is necessarily socially _useless_. Rather, I see that it is likely useful in a moderately small way spread out over _a lot_ of people (most people in the markets). The benefit is not obvious or concrete, but that doesn't mean it doesn't exist.

Similarly, the article complains about how bots just quote each other prices without necessarily making a trade. I don't see how this is a bad thing. All it means is that their quotes are at a much _higher resolution_ than manual quotes, that's all. This seems like it would generally be a good thing.

Now, I'm not saying that HFT is not without its own risk or issues--they're just not the issues brought up in the article. Or, in fact, in most popular articles: popular reporters want to turn HFT into a moral issue and paint HFT firms as evil manipulators, when they really aren't. The actual risks of HFT are more structural and technical, which, I suppose, is not great for a broad audience or lots of pageviews!

It's also not immediately clear that HFT should be banned or how to deal with it. Many proposals I've heard would reduce liquidity beyond affecting just HFT, raising real costs for consumers. Ultimately, this is why there has not been much regulation in the space!

[1]: [http://247wallst.com/investing/2013/03/24/high-frequency- tra...](http://247wallst.com/investing/2013/03/24/high-frequency-trading- profits-crushedbut-danger-remains-unchecked/)

<comment><USER3> See, here's the thing I don't understand about liquidity: If it's so valuable for trades to execute in microseconds instead of seconds, and the stock exchanges recognize this value and provide co-location etc to enable it, why are so many stock exchanges closed for half to two thirds of the day? [1]

Surely the 15+ hour shut downs are a much bigger limit to liquidity than a few microseconds here and there?

There's obviously no technical reason - I don't see Amazon or Google closing down their websites from 4pm to 9:30am. And if it's about the release of news, that only really needs a window of an hour or so.

[1] [https://en.wikipedia.org/wiki/List_of_stock_exchange_opening...](https://en.wikipedia.org/wiki/List_of_stock_exchange_opening_times)

<comment><USER4> I worked in the industry for a little while.

At this point, some companies depend on having that daily downtime. Their whole development is based around the fact that they will have guaranteed downtime. It's built right into their software stack.

Trying to fiddle with this expected downtime would throw (parts of) the industry into turmoil.

It's just a historical quirk, but it's probably here to stay.

<comment><USER5> Surely there are ways to get rid of it without the transition being so traumatic. For example, the change could be announced a few years prior, and the downtime could go down by an hour per year.

<comment><USER4> To put things into perspective, the company I worked for responded to bug reports by hiring a team of people whose role was to manually alter the database any time a customer reported a data problem. Dozens of times per day. In other words, instead of fixing the software, it somehow became a reasonable idea to dedicate employees to fixing the symptoms by hand. It made sense in hindsight: they were making so much money that they took the path of least resistance. Paying employees to fix the problem immediately was quicker than trying to hunt down a competent programmer to try to fix the problem without causing more problems.

The change would be traumatic no matter how long they are given to plan for it.

Oh, here's another reason I forgot to mention: You can capture huge profits by exploiting the opening and closing few seconds of the market. A huge portion of all daily trades happen within the first few and last few seconds of the day. So there's a financial incentive to leave things as they are.

</comment></comment></comment></comment></comment><comment><USER6> I don't get it. The article first criticizes HFT for making markets rather than speculating, incorrectly asserting that it's somehow a tax on traders (hint: don't cross the spread if you don't want to pay the "tax"). Then it reveals that HFT does speculate - they pay people to do market research and trade on that basis, which is somehow also evil.

Damned if they do, damned if they don't I guess.

The authors reasoning in going from HFT engaging in speculation to a financial transaction tax is unclear. He wants to prevent speculation and information gathering? Or prevent people from speculating quickly?

<comment><USER7> The author's point is clear - that HFT adds no value to society ("socially worthless").

I don't believe that he wants to _prevent_ anything, but he suggests that trades should be taxed to create some value to society from this. He is suggesting their value (at the moment) is exclusively to the benefit of making rich people - who can pay for access early information and technology - richer.

<comment><USER8> Traders are already taxed. They make money from their trades and pay income taxes on this trading. If, however, you tax the trading itself, there will be less of it, significantly less and, most likely, the total taxes collected will decrease

<comment><USER7> This argument seems to apply equivalently to VAT/sales tax, which in my mind makes it weak. (Consumers are already taxed on their income etc)

There's no reason to believe total taxes collected will decrease. If actors still benefit from HFT post-taxation, they will still trade, and pay the tax.

<comment><USER8> Sorry but you are clueless. Taxing the trading itself will raise the cost of trading, this making it less profitable if it is less profitable people will do less of it.

</comment></comment></comment></comment></comment><comment><USER8> Here is the problem that I have with this whole "socially useful" line of reasoning: Do we have philosopher kings or benevolent rules who are able to accurately designate social usefullness and ban or allow things on the basis of it? Is facebook or snapchat socially useful? Are hamburgers socially useful? what about french fries? Whether or not HFT is socially useful is irrelevant. Since there is no harm to a long term investor from someone trading 50 millisecond early, etc. , HFT should be left alone to do what it wants to do.

<comment><USER9> It's not about banning or allowing, it's about counting the true costs and benefits of the trade, not the immediate effects. And you don't need philosopher kings to do this, just basic math and science. This particular article may not make a good case for the harm of HFT, but that doesn't mean there isn't any. And yes, there are serious researchers that are pointing out hidden costs for things like facebook, hamburgers, and french fries. Those things may have demonstrable value, but that doesn't mean the value outweighs the cost or that they are correctly priced. For example, some studies put the true price of a hamburger at around $30 based on the burden put on healthcare and the environment, which are ultimately paid by other people. With perfect information, those costs should be factored into the trade, but they aren't. So, while HFT might have some small benefit to market liquidity as claimed by other comments, I can easily believe there are hidden costs that would outweigh such small benefits. I don't have any evidence to provide in this specific case, but I would support research to investigate whether we are overcounting the benefits or undercounting the costs.

<comment><USER8> Right, by this logic literally anything might have a hidden cost that exceeds the demonstrable benefit. The onus is on the ones crying wolf to present concrete evidence. Otherwise, we will end up living in Soviet Union or Nazi Germany ( yes yes I know, Godwin's law)

</comment></comment></comment><comment><USER10> I assume folks who advocate for a transaction tax don't actually want less transactions, rather they want more "real" transactions and a less artificially volatile market place.

Unfortunately, a transaction tax would create the exact opposite of that situation. The hypothesis that if there were a transaction tax there would be less transactions is incorrect. What would happen is that transaction quantities would get bigger in order to overcome the new added cost. These larger transactions would magnify the risk at play in the market place. This in turn would raise the reward for being able to pull out of quotes faster and/or to misrepresent the riskiness of your trading strategy.

So a transaction tax would actually incentivize more "false" liquidity and work to the betterment of companies that are more risky.

What HFT systems actually do, is allow firms to "pay" for priority of an order at a price level, by investing in network infrastructure/algorithms. If you want remove that advantage the easiest way would be a system where you transparently pay for priority of an order. The system with the least likely negative side impacts of this would be making arbitrary price level sizes. That is, instead of quoting down only the penny level, let people quote arbitrary (or some fixed but very small) decimals of a penny. That way if you really want to pay up for priority, you can just increment your order slightly and actually pay for the privilege.

<comment><USER11> We actually have a system similar to what you describe in your last paragraph with the three "inverted" US equity exchanges where liquidity providers pay a fee and liquidity takers receive a rebate. It means that shares posted to the inverted exchanges are cheaper (net of fees) to aggressors than shares posted to other exchanges, so liquidity takers with a smart order router will look first to the inverted exchanges before the other exchanges.

</comment></comment><comment><USER12> Lost me at _That brings us to high-frequency trading (HFT) hedge funds. These funds use computer algorithms—a.k.a.: algobots_

No-one says this. I'm not involved in HFT myself but I know a bunch of people who are, there is a jargon word, but it's not that.

<comment><USER13> You tend to hear high frequency traders refer to the code that makes pricing and trading decisions as a _system_ , or _signal_ , or _model_ , or (very occasionally) _algo_ (all refer to slightly different things) but I have never heard them refer to the code that makes trading decisions as a _bot_ or _algobot_.

Source: I used to work in high frequency trading.

</comment></comment><comment><USER14> Anybody that has looking into things like the voodoo of "doji candlestick strategy" etc realizes that the entire market is full of people reading tea leaves.

99% of the portfolio managers, investment professionals have no more luck in picking stock then HFT or these other strategies.

It's basically gambling in one form or another. The ony way to get ahead in that world is to cheat.

HFT by itself isnt; a problem. When juiced with regular insider information, front running your own clients etc it's a massively profitable biz.

The biggest crowd that hates HFT is the stock pickers, day traders (any left?) and others that work int he investment biz.

They have had a nice scam going for the last hundred years and you are ruining their party.

Haw can they go have cocktails at 4 pm every day when computer programmers are working hard all night long?

The other group of course are the luddites. Afraid of any advance in technology. Other favorite causes, "Kids and violent video games". "The 100 mile diet" "environmental anything".

</comment><comment><USER15> The primary function of the stock market is to exchange ownership (shares) in a company. It's odd that we seem to have forgotten that. What value is there in a computer owning a stock for 10 milliseconds?

<comment><USER16> I've read elsewhere on here that the value of high-frequency trading is that it reduces transaction costs and increases liquidity in the market. I.e. it makes it easier for the humans to buy and sell at the prices they wish to buy and sell at.

Assuming that's true, the question then becomes what are the costs and externalities of HFT and, in balance, are we willing to make those trade-offs? I haven't seen anything addressing those issues yet, but I haven't been looking either.

HFT experts want to weigh in, pro/con/otherwise?

<comment><USER6> Since most of the people commenting here don't seem to even understand HFT, I'll just leave this here (a tutorial I wrote a while back):

[http://www.chrisstucchio.com/blog/2012/hft_apology.html](http://www.chrisstucchio.com/blog/2012/hft_apology.html)

[http://www.chrisstucchio.com/blog/2012/hft_apology2.html](http://www.chrisstucchio.com/blog/2012/hft_apology2.html)

[http://www.chrisstucchio.com/blog/2012/hft_whats_broken.html](http://www.chrisstucchio.com/blog/2012/hft_whats_broken.html)

<comment><USER17> you should probably link part 2 from the end of part 1, if not it's not obvious that you did write part 2.

<comment><USER6> Thanks.

</comment></comment></comment></comment></comment><comment><USER18> The clueless preaching to the more clueless?

Early data access has been around for a decade and generally has NOTHING to do with HFT. Events desks typically have very different architecture than other groups in HFT, and, well, are a very very small cog.

</comment><comment><USER19> > I'm pretty sure—or at least I hope—that Red Auerbach was kidding when he > told a gym full of kids to cheat to get ahead.

He didn't tell them to cheat. He told them that to gain competitive advantage you cheat. Games are mostly random so you can get ahead without getting competitive advantage. And you don't even need to get ahead to have almost all benefits of playing the game or even some other benefits that you can't get when you have an advantage.

I think that attitude towards cheaters is pretty much an american (maybe british?) cultural thing. Lot's of people were successfully taught to be honest, and if they can't be honest to defend the ideal of honesty by teaching honesty and never admitting their dishonesty. People who are honest about their dishonesty meet exasperation and disbelieve.

> If a company sold hedge funds an early look at their earnings, it'd be > insider trading. But when a third-party like Business Wire sells hedge funds > an early, albeit split-second, look at corporate earnings, it's perfectly > legal. It's nuts.

Nuts is the fact that insider trading is illegal. It's unenforceable idea of how to make intrinsically unfair game appear sort of fair. It comes from the fact that shares are not as attractive as they need to be on their own. Possessing part of some company and getting dividends when the company decides to pay them is not incentive enough to shell out your cash and give it to the company that needs the cash to develop.

Since people love to participate in lotteries (before taxes it was the way money was gathered for expensive projects, people were just voluntarily were giving their money away in hopes of winning the big prize) they attached sort of casino to the idea of shares. The game is mostly: guess future ratio of supply and demand for pieces of paper. But people don't like to play in the casinos that are known to rig the games and despite the fact that price is random as it depends on so many different pieces of information some information can have some predictable influence. So casino (exchange and companies) pinky swear to prevent anyone from acting on the knowledge that gamers didn't have chance to familiarize themselves with. It works. I makes the game look fair. Of course insider still trading exists because you can't tell it apart from luck if you can't trace where the information leaked. And you can do that only rarely.

</comment><comment><USER20> I don't know how I personally feel about HFT. I don't have a high enough view of the system as a whole to make a determination if HFT is or will be a problem.

But the mention ([http://www.cnbc.com/id/100809395](http://www.cnbc.com/id/100809395)) of Reuters selling data to customers 2 seconds before the conference calls (which occurr 5 minutes before the public receives the data) unsettles me a bit. Two seconds isn't a long time except when you consider that HFT operates in milli, micro, or maybe even nano seconds.

I am not sure whether I would go as far as to consider it insider trading, but I do think the conference call and the data meant for HFT should all be released at the same time as the public data.

<comment><USER21> But that isn't public data, it is private research.

That a university is doing the work muddies the water, but pretend that a private institute is selling access to its research, what benefit is there in telling it how to sell the data?

</comment></comment><comment><USER22> I don't mind one of the few industries where developers can get relatively good money without being a founder (here in UK).

</comment><comment><USER23> No new insights in this article.

What I've been thinking about recently though is that the problems HFT companies work on may have unexpected benefits in other fields. For instance they are working on things like machine learning, transmission speed, long range networking, mathematical modelling, and software. If we were to ban HFT we would lose the potential upside of all this. In the words of NN Taleb, this sort of 'stochastic tinkering' is primarily how scientific progress is made.

</comment><comment><USER24> Key quote: "Now, what they do is strictly legal".

This article felt like it was written by a college freshman who just took their first class on "social justice".

</comment><comment><USER25> An example of privileged, well-connected parties systematically winning asymmetric zero-sum games against the not so well connected.

I'll believe that HFT adds liquidity to the market when the typical retirement horizon is 15 milliseconds. HFT proponents seem not to (or pretend not to) understand diminishing returns where "adding liquidity to the market" is concerned.

</comment><comment><USER26> Distributed exchange architecture is an interesting alternative:

[https://ripple.com/blog/ripples-distributed-exchange-and- the...](https://ripple.com/blog/ripples-distributed-exchange-and-the-high- frequency-trading-arms-race/)

When there's no central location towards which orders need to race to get time stamped, the whole low latency arms race seems unnecessary.

There's also no central place to co-locate servers.

Some of the existing traditional (centralized) exchanges are making 20-30%+ of their revenues from co-location and data fees. So they have little incentive to change. They cater to HFT because it's a big driver of their bottom line...

</comment><comment><USER27> He starts with an anecdote about cheating and then lays out HFT an implies it is cheating without saying how. If he had to defend his assertion that it is cheating he wouldn't have an article.

</comment><comment><USER28> I've never really understood the stock market. Is this basically how it works?

A person can make or sell things, but that person is limited in the scope of their business by their available capital. Thus, they can increase their capital by either securing a business loan or by making their company "public." Securing a business loan is risky, because they will still have to pay back the loan regardless of whether or not their company makes any money. Going public carries additional risks, but at least they aren't on the hook if the business fails - and there's an added benefit of the potential for enormous gains in capital which can further increase their business potential.

So, the person "goes public" which is extremely complex and time consuming, but let's say they are able to convince 100 people that they should each buy a "share" of the company. This means that the more money that the company earns in profit, that a little bit of that profit is "owned" by each person who owns a share. Right? (I am legitimately asking here, because as I said I really don't understand much of the way it works.)

So, now we have stock exchanges. These are places that people can buy, sell, or trade stocks of different companies for cash or other assets? I own one share of Company A and that share is worth $51 right now. Later in the day, however, we see that company A has earned a little bit more money than we thought it was going to, and so now my stock is worth $53. And I originally purchased the stock for $47, so I can potentially sell that stock for a $6 profit, or I can hang on to it and hope that it goes a little higher.

However, humans can only act so quickly, and day-traders and short-sellers act on stocks in the span of minutes or hours. So if I purchase 10,000 shares of Company B at 10:00 for $5 each, and then sell those same 10,000 shares back at 10:04 for $5.02 each, then I have made a small profit. And large firms do this hundreds of times each day, with dozens of companies, and likely tens of thousands of stocks. Right?

So, HFT does the same thing. Except, instead of making a purchase-sell decision every few minutes, they do it every few microseconds. And the returns per transaction are something like... .0000034 per share (this is a guess), but over tens of thousands of shares, and millions of times a day. Right?

This, however, is where my understanding breaks down completely.

HFT obviously benefits a company that can wield it. If my hedge fund can hire the programmers, run the servers, and buy the licenses to the data then I stand to make huge profits for a minimal investment when my HFT "algobots (lol)" do their thing. But I don't understand how this benefits the rest of the market?

I'm guessing that most of these HFT bots are not being run by small-time investors, and in fact that the trades made by small-time investors will be heavily influenced by the HFT trades that are made in-between the time the guy using E-Trades can point on the "Buy!" button and the time he can click on it.

And as a consumer who does not participate in the stock market (in that I do not have an investment portfolio, I realize that the stock market influences me regardless of whether or not I put money into it), I really don't get how HFT helps me.

What it looks like to me, is that players who have the most money, and who have the best technology will have a benefit over players who lack those resources. And so while there's no evidence (that I'm aware of) that these HFT-using companies are committing any malfeasance, it looks like the natural side-effect is that the market becomes more one-sided.

I would liken this to a professional athlete using steroids (let's pretend that steroids aren't illegal). Steroid use may stem from the player simply wanting to maximize their ability to use their body, and so they enhance their muscles and work hard to be able to control them. This player isn't actively trying to cheat, he is simply using technology to overcome a natural hurdle (let's also assume that this same player has, through hard work, literally pushed their body to the limit of what it can naturally achieve). However, a similar player who has also pushed their body to the limit is either unable or unwilling to use steroids, and thus they are unable to compete against the other due to the slight technical advantage.

Is this a true analogy?

<comment><USER29> I'm not entirely clear on the exact process either, but I think your initial summary has it mostly correct. There are additional complexities in Share Dividends (you receive a fraction of the companies profits proportional to your number of shares owned, which incentivises not-selling, to a point)

The basic issue that HFT (and markets in general) seek to solve is liquidity - the ability to buy & sell when you want, rather than having to wait while a deal is worked out. Consider the differences in process when buying/selling a commodity such as gold, vs buying a particular house.

There's a good overview of the mechanics & benefits of [HF]T in the 'A High Frequency Trader's Apology'[0] series, written by HN member yummyfajitas.

[0] [http://www.chrisstucchio.com/blog/2012/hft_apology.html](http://www.chrisstucchio.com/blog/2012/hft_apology.html)

<comment><USER30> That's an excellent series of posts. Thanks for the link!

</comment></comment></comment><comment><USER31> HFT is more likely about front-loading their own customers' orders than it is about reacting efficiently to price changes.

</comment><comment><USER32> The problem is someone is _always_ going to get important information and act on it first in a market. A tax wouldn't stop that, it would just make small transactions more expensive (for both parties.) I don't know if this is a real problem or how to fix it but this article is entirely useless.

</comment><comment><USER33> maybe i didn't read the piece accurately enough, but i don't get why it's cheating. It's about ingenuity and the ability to allocate money to where you think the market will move. It's been this way since the beginning. We do the samething with our 401k.

</comment><comment><USER34> Are there any protections in place for if an investor is hovering a cursor over a buy button that the stock doesn't get pumped up?

</comment><comment><USER35> "High-Speed" is redundant.)

With a _very few_ exceptions, modern trading is a form of cheating, based on mass-media powered deceptions (we have full-time satellite channel - TLC, which promotes premium (read: overpriced) and/or "chap-but-healthy" fast-food chains) and "optimizations" such as purchasing a "30% meat stuff" at a penny price and adding lots of spices and synthetic sauces, etc.)

Why should it be different in finance? Especially in speculative trading.)

</comment><comment><USER36> The stock exchange has just become the ultimate casino today. Yesterday, stock exchange helped to build companies, to have some security against bad crops and so on ... but that has changed. More and more money is just made by gambling and the more money is made, the more money is again put into the big gambling machine. It is legal, but just gambling and we all have to pay the price, because the gamblers carry the wealth of the Earth away -- and the others are left empty.

</comment><comment><USER37> HST doesn't sound that useful, but the article didn't really say much or show that they're cheaters.

</comment><comment><USER38> In other news gravity works on apples and spicy food can be enjoyable.

</comment><comment><USER39> Actually, HFT is socially useful in the same way that Cold War research, even though most of it never went anywhere, is.

It bids up the price of talent, and that's an inherent social good because it means there is a chance for smart people to get into decision-making positions (which, otherwise, go to entitled, and mostly untalented, incumbents and their shitty offspring). Google and Amazon would _not_ be paying $140k per year for mid-career software engineers, were it not for the hedge funds paying $200k.

VC-istan is terrible, with founders lucky to get 10% and earliest employees getting 0.1-1%, but if Wall Street wasn't absorbing most of the top talent (and it is) those numbers would be closer to 1% and 0.001-0.05%. Instead of very few people getting rich in the tech lottery, it'd be almost no one, because the founders and early engineers would have zero leverage.

The HN crowd likes to assume that talented people will, as if it were a law of nature, have options to rise economically and socially. It's not so. If it weren't for socially useless talent vampires like HFT and online ad targeting, talent would have even _less_ leverage against the good-ol'-boy networks and widespread stagnation would ensue.

(High levels of funding, probably originating from governments at first, for basic research would achieve the same effect in a socially use _ful_ way, but I wouldn't hold my breath.)

<comment><USER40> Interesting way too take the conversation but valid.</comment></comment>


Facebook Kicks All Ex-Facebook Employees Out of Messenger Group Chats - <AUTHOR> Do you see this happening in your group chats? <comment><USER2> Is there any blog/news website that has this? I'm interested, but details would be great .

</comment><comment><USER3> You mean they kicked them out of ALL Group Chats - even ones not related to work?

<comment><USER4> Yep, happened to me. Strangely it was a client side thing, only kicking me out of group chats I had opened. I could read messages through the notifications if I didn't open the chat directly.

</comment></comment><comment><USER5> This happened to me!</comment>


Implement table partitioning - <AUTHOR> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 <comment><USER2> Any support for "rolling" partitions? e.g. A partition for data updated less than a day ago, another for data from 2-7 days ago, etc.

I miss this from Oracle; it allows nice index optimizations as the query patterns are different for recent data vs. historical data.

I think it could be set up with a mess of triggers and a cron job... but it would be nice to have a canonical way to do this.

<comment><USER3> How does this work in Oracle? Seeing as the partitioning constraint would be time-dependent, wouldn't it need to re-evaluate it at regular intervals in order to shuffle data around? Is the feature explicitly time-oriented?

<comment><USER4> I don't think oracle can do this exactly but the query planner does understand time based partitions so if you do something like:

       SELECT * FROM partitioned_table WHERE partition_date_key > SYSDATE - 1;

The query planner will only use the most recent partition. Combine this with Oracle's ability to merge partitions and you get "daily" partitions that become "weekly" partitions when the new week starts. Alternately you could wait a month and combine all the days of last month into a single partition and then even combine months into years.

The partition intervals are based on specific dates/times, not on the relative time from query execution.

Oracle also supports row movement which is the biggest missing feature here I believe.

</comment></comment></comment><comment><AUTHOR> The conversation on the patches are really interesting: [https://www.postgresql.org/message- id/flat/55D3093C.5010800@...](https://www.postgresql.org/message- firstname.lastname@example.comfirstname.lastname@example.com) [https://www.postgresql.org/message- id/flat/ad16e2f5-fc7c-cc2...](https://www.postgresql.org/message- email@example.comemail@example.com)

<comment><USER5> I'm always amazed by the PG community - it seems like such a constructive place.

Those patches are absolutely insane. Makes you remember how much hard work goes into building the software you use on a day to day basis.

[https://www.postgresql.org/message- id/attachment/45478/0001-...](https://www.postgresql.org/message- id/attachment/45478/0001-Catalog-and-DDL-for-partitioned-tables.patch)

<comment><USER6> I've been professionally focused on PostgreSQL based works for the last 5 years. At the highest point of the BigData hype I sometimes felt a little bit off-track, because I never got the time to investigate NoSQL solutions...

Only recently did I realize that being focused on actual data and how to process it inside PostgreSQL was maybe the best way I could spend my working time. I really can't say what's the best part of PostgreSQL, the hyperactive community, the rock solid and clear documentation or the constant roll-out of efficient, non-disruptive, user-focused features...

</comment></comment></comment><comment><USER7> If you also didn't know what exactly partitioned tables are, here's a nice introduction from Microsoft:

[https://technet.microsoft.com/en- us/library/ms190787(v=sql.1...](https://technet.microsoft.com/en- us/library/ms190787\(v=sql.105\).aspx)

It is for the SQL server but I assume it would be mostly relevant. Please correct me if I'm wrong.

<comment><USER8> So this is all about partitioning data into different storage files on the same server? What is the main benefit of that?

<comment><USER9> Metadata operations on partitions can be very fast. One simple example is date based housekeeping. Deleting a month of data will be quite intensive on most databases, whereby dropping a partition from the table is effectively instant.

Partion switching is also fast. Say you have a summary table that is rolled up by month, but you want to recalculate the summaries every so often. You can build a month into a new table and then switch the new table for a partition in the summary table.

<comment><USER10> When the circumstances allow it ('cause there are some limitations on where it can be used), this pattern is HUGE. We've got a few places in our system that do this, and the optimization achieved an improvement of a couple orders of magnitude.

</comment></comment></comment></comment><comment><USER11> I don't get it? Table partition is already supported in PostgreSQL now and has been for a long time now (at least since 8.1); Where I work we utilize table partitioning with PostgreSQL 9.4 on the product we're developing.

[https://www.postgresql.org/docs/current/static/ddl- partition...](https://www.postgresql.org/docs/current/static/ddl- partitioning.html)

<comment><USER12> It sounds like this is column level partitioning.Each column or columns (based on partitioning expression) is stored as different subtable (or something similar) on disk.If only few columns are frequently accessed, they can be put on cache/faster disk or other neat optimizations for join processing.

<comment><USER6> Maybe I don't get you, but i don't think so, PostgreSQL is not a columnar database.

If i got this patch right, each partitioned table will have the same data structure and store whole rows (it's even more restrictive than previous inheritance mechanism that allowed extending by adding additional columns).

Column or expression should only define in which table an inserted row is supposed to be stored. A single row will never been torn apart. Still it look like a foundation that facilitate sharding BigData(Set) between multiple servers when used in conjunction with foreign data. However a lot of performance improvements will still be needed to compete against solid NoSQL projects (in which you really have a BigData use case).

But looking a bit forward, developing performances improvements on top of an ACID compliant distributed database seems less difficult than to develop a NoSQL project for it to become ACID.

<comment><USER13> Generally PostgreSQL is a row database but Citus has release column drivers that make it perform similar to other columnar databases.

But this patch is about horizontal partitions.

</comment></comment></comment></comment><comment><USER14> About donations: I believe PostgreSQL now deserves more advertising and marketing to develop its adoption in major companies and, hence, get more funding. If I donate on the website, it says it will help conferences. Where should I donate?

</comment><comment><USER15> Supposing the case in which all partitions are on the same disk and that you manage to index your data well enough according to your usage that postgres does not need to do full table scans, are there any additional performance benefits on partitioning?

<comment><USER16> Yes. Less latch contention for nodes of a single btree index, for instance.

<comment><USER15> I didn't know what latch is, so I googled it and found a nice explanation:

[https://oracle2amar.wordpress.com/2010/07/09/what-are- latche...](https://oracle2amar.wordpress.com/2010/07/09/what-are-latches-and- what-causes-latch-contention/)

"A latch is a type of a lock that can be very quickly acquired and freed."

That brings me a couple more questions:

1\. May I infer then that the only benefit from partitioning the table (fully located on the same disk) that can not be achieved by indexes is that queries will wait less time for this kind of lock to be released?

2\. May I assume while a table is only being read and not changed, there's no performance gain from partitioning a table (fully located on the same disk) that can not be achieved by indexes?

<comment><USER17> There are other possibilities as well. For example, if your partitioning strategy is such that it improves the selectivity of an index, it could improve query plans for queries that were on an index that was less selective. As an example, I once had a table with over a billion rows distributed among ~100 tenants on which queries were typically run by tenant and date range. Partitioning that table by tenant dramatically improved the performance of those queries because those queries no longer had to scan through rows of which only ~1% were for the tenant of interest.

<comment><USER15> If you had built composite index instead, wouldn't it work just the same towards improving the performance? Well I can see that an composite index would occupy more space while partitioning wouldn't, and that should be something to take into consideration. But performance-wise, wouldn't it be the same?

<comment><USER17> No, for example, a composite index on (tenant, date) would be highly non- selective whereas an index on date in each individual tenant partition is highly selective and therefore higher-performance (in my case, much higher performance).

<comment><USER15> What if you made an index on (date, tenant) instead?

<comment><USER16> The issue he or she is referring to is that the underlying rows are fragmented within each fetched page (so you might need to fetch 40 pages for 40 index entries, even if they would all fit on one partitioned page). Fiddling with the index order isn't going to change that (the current index order is already optimal for that type of query). There's another solution, which is to expand the index to include any covered rows so you can use index-only scans and not hit the main rows at all, but that's trading away a large amount of index size, which you usually want to avoid unless you have no other choice.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> This message was confusing to me because I've been using/abusing Postgres inheritance for partitioning for so long that I forgot Postgres didn't technically have a feature called "partitioning".

What I'm looking forward to finding out is if I can take an arbitrary expression on a column and have it derive all the same benefits of range partitioning like constraint exclusion.

</comment><comment><USER19> I really like this addition. We store a lot of data for different customers, and most of our queries are only about data from a single customer. If I understand it correctly, if we would partition by customer_id, once the query planner is able to take advantage of this new feature, it will be much faster to do such queries as it won't have to wade through rows of data from other customers.

Another common use case is that we want to know an average number for all/some customers. To do this, we run a subquery grouped by customer, and then calculate the average in a surrounding query. I hope that the query builder wil eventually become smart enough to use the GROUP BY clause to distribute this subquery to the different partitions.

</comment><comment><USER20> I just tried to implement table partitioning in PostgreSQL 9.6 this week. With some triggers and check constraints this seem to work quite nicely, but I was a bit disappointed that hash based partitioning is currently not possible (at least not without extensions).

Will hash based partitioning be included in PostgreSQL 10? The post notes

      A partitioning "column" can be an expression.

so I can assume it will be supported?

<comment><USER21> Not natively, as in there is no PARTITION BY HASH (<list-of-columns>). What limitations do you face when trying to roll-your-own hash partitioning using check constraints (in 9.6)?

<comment><USER20> I wanted to partition a table by the foreign key, as the table receives a few hundred rows per foreign key per hour (it is a timeseries db).

So I figured partitioning the table by foreign key would group all data together in a way that allows for faster access (typical access pattern would be select * where foreign_key = x). However, as the number of keys in the foreign table is unbounded and can be quite large, I wanted to partition the data to a limited number of tables, with

      mod(foreign_key, number_of_partions)

If I understood correctly, check constraints can't operate on a calculated value

<comment><USER21> Yes, it is not possible to optimize (ie, prune useless partitions for quicker access) the query select * from tab where key = x. You'd need actual hash partitioning for that. The mechanism Postgres uses to perform partition- pruning (constraint exclusion) does not work for the hashing case.

</comment></comment></comment></comment><comment><USER21> ...this is the beginning, not the end... [https://www.postgresql.org/message- id/CA%2BTgmobTxn2%2B0x96h...](https://www.postgresql.org/message- id/CA%2BTgmobTxn2%2B0x96h5Le%2BGOK5kw3J37SRveNfzEdx9s5-Yd8vA%40mail.gmail.com)

</comment><comment><USER22> While seemingly extensive, I don't quite like the commit message.

I doesn't say what TP _is_ , and what its use cases would be. That's the first thing you should say, else how am I going to understand / keep interest in the rest of the text?

<comment><USER23> The commit is written by postgres developers for postgres developers. I would say that 90% of the intended audience of that commit message doesn't need an explanation what table partitioning does.

For them this would be needless clutter that's not at all relevant to the commit.

Once we're reaching the 10.0 release, human-friendly release notes, additional manual chapters and sample code will be written for the users to understand (in-fact, the commit linked by this submission already contains quite a bit of additional documentation to be added to the manual).</comment></comment>


Ask HN: I just got my first team lead. What should I do? - <AUTHOR> Dear Community,
Lucky me (29, Software Engineer from Berlin, Germany) recently got a new job as a Lead Architect for a startup.
Now I'd say I'm not a bad engineer, but I've never been much of a "people person" or a natural leader. Although my colleagues treat me with a lot of respect, I still feel a little awkward. I'm a total newcomer to the "business" of managing, regularly keeping up with people and doing hiring/firing decisions, but I think I'm worst at delegating. Since the company is still pretty small, there's no choice for me than to get my hands dirty on coding and sysadmin stuff as well. Unfortunately, I'd rather do it all myself than entrusting and encouraging others with it, so I'm kind of playing my old role. Also, I'm having a hard time being a good listener, since I'm always coming up with my own ideas and notice that I'm mostly talking about myself which doesn't exactly make me more likeable, but it's hard to stop.
Reading "How to win friends and influence people" already helped me a lot with my people's skills, but I'm still struggling to get it all into practice.
Have you ever been in a similar situation? Do you know of any great resources, tips, tricks, hacks, communities or seminars short of doing an MBA (which I definitely wouldn't do due to time constraints and the bullshit factor)?
I'd really appreciate your help, especially from the engineer-turned-manager folks!
Best,
Dom <comment><USER3> Three years ago, I was the sole employee/founder of my startup. Today, I'm CTO of a 21-person company with a 6-person dev team.

As an individual developer, my default loop is "Find something to do. Do it. Repeat."

As a CTO, my default loop is "First, cycle through all my employees and make sure that I have equipped them to be happy and productive in their jobs. Second, find something to do. If possible, delegate it; if not, do it. Repeat."

<comment><USER4> "First, cycle through all my employees and make sure that I have equipped them to be happy and productive in their jobs. Second, find something to do. If possible, delegate it; if not, do it. Repeat."

This is what I did in my role as team leader and earned the equivalent of Employee of the Year at a large firm. Its quite simple to say, more difficult to successfully implement and often even harder to quantify during a subsequent job interview, because when you do it well, to you its common sense or straight forward doing your job. As a result, its not necessarily easy to train into the behaviour of others. But it is quite easy to undersell (its easy for you) or oversell (can sound arrogant) how you did it and doesn't have the impact it should or could have on a hiring manager. Obviously referrals from those you worked with can be a much better testament to the impact you provided.

</comment></comment><comment><USER5> I made a similar transition myself and have one piece of advice for you.

Forget about all that "leadership" and "management" bullshit. Seriously. When you have direct reports your primary function is to serve them. I'm not kidding - I know it sounds all squishy and kumbaya-ish but if you think about what it means to serve somebody else you'll have a really good compass to guide you through your day.

Everybody seems to throw around bits of advice around what to do and even how to do it. The problem is every person is different and since people make up teams, every team is different. Plus, they change. Don't get lost in the what and the how until you understand the why. Everybody on your team has different needs and serving those people means understanding their needs. Some people need to be micro-managed and some people need to be given tons of space. Don't let their needs/situation effect your respect for them and always remember that people change.

Your to "why" will be different than anybody else's answer to that question and will give you immense insight into which "what" and "how" things you pick up from all that advice that is out there. It will also determine what kind of a leader/manager you are. This is important.

Identify what makes you and others around you happy and you will probably find yourself asking "what should I do?" a lot less often. Oh, and in case it's not clear, don't be so naive to think that "happy" is all fun and games and wine and roses and group hugs. And don't forget that you serve the "team" too - it's an entity with its own needs and challenges.

<comment><USER6> Absolutely agreed.

There's a saying, "shit rolls downhill." I'd argue that a surprising amount of your job will be to keep that from happening to your people. Providing top- cover is one of the most important ways you can serve your team. Keep the crap off of them so they can concentrate on doing there jobs.

<comment><USER5> Yup. It's all about crap reduction. Nobody wants to deal with stupid shit. Most grown-ups understand life involves the occasional bit of excrement and can deal with it.

One of the biggest mistakes I see managers make is failing to view people as people. The shit flowing downhill is a symptom and not a given fact of life.

</comment></comment></comment><comment><USER7> _I think I'm worst at delegating_

 _I'm having a hard time being a good listener_

Wow that is a description of me 10 years ago to the T. I was always the guy that people turn to and the guy that pulled the project out. It can and does go to ones head. Be very careful to not become arrogant, I really wish someone gave me that advice 10 years ago.

As for your case specifically, the delegation is going to be the hardest one and the one that you have to cross the chasm on. Given your nature (I know from experience) it will be hard but you just have to trust in your people. Hire people that you believe are smarter than you, this will help in delegation because you will perceive their opinions higher than your own. Also try to remember, you design systems the way you do because it worked for you, they will design it their different way because they are drawing on what worked for them, look at it as an opportunity to learn a different way of doing things. Many times when people like you and I enter this type of role we believe that we are the authority, it can make working with our personality type unbearable when you are a subordinate. Instead take it as an opportunity to learn. Help them make their solutions better, not make your solutions better. Just because you are the lead does not mean you are the best at every situation, be humble and try to be an eternal student, that is the best advice I can give you.

</comment><comment><USER8> Shortly before I started managing engineers I read "Managing Humans" (I'd already been following <http://www.randsinrepose.com/>) and found it helpful. One of the best resources I found was (luckily) my own boss. Find others in a similar (or higher) position and talk with them regularly, openly, and candidly about any challenges you're facing.

I wish I had better advice, but what you'll find is that being a good manager/team lead is at least as hard as your old job (and probably harder). Continuing to do your old job alongside it, while probably a good idea for your own job satisfaction/sanity, will only make it harder.

Random bits of advice I find helpful:

* Your primary job is to shield your direct reports from management BS (false priorities, unrealistic deadlines, company drama); while this is less of a problem at a small startup, don't ignore it. Your secondary job is to make your direct reports look good; promote what they're doing and make sure what they're doing is aligned with the company's goals.

* Schedule 1:1 meetings. See Rands' advice on how to structure and run them, but basically keep them short, informal, and regular. Start with a softball and use it as a time for your direct reports to warn you about any upcoming problems that may be bubbling. Avoid the temptation for status reports, one larger team meeting instead, etc. Sit down with each individual direct report and get to know them better.

* Set clear goals and priorities for everyone.

* Avoid the temptation to micro-manage. You may eventually find you have an employee who has to be micromanaged, but most people hate it and will find it counter-productive. While this sounds obvious, it's hard for someone who likely got to their new management position because they were the best at the job they're now managing. Let people make mistakes and then let them recover from them.

</comment><comment><USER9> The first thing you need to do is learn the capabilities of your team.

Who are the best programmers? Who are the best programmers for the given types of problems you have to solve? Who are the most creative thinkers? Who is good at meeting deadlines?

If somebody is bad at meeting deadlines, why?

One of the best programmers I've ever worked with was always missing deadlines. Turns out, it was only because he was really bad at estimating time. Once I learned that, and started handling some of his estimates for him, he was the best programmer on paper too.

As for managing, I try not to micro-manage, but it's easier to get a sense of who does and doesn't need it once you understand, from a manager's perspective, who is capable of what, and to what degree of consistency.

For the actual management, most of the time, I would just periodically see if anybody needed any assistance, and let them know that I was always happy to help where needed.

<comment><AUTHOR> Great advice, thanks! On a sidenote, that guy:

"One of the best programmers I've ever worked with was always missing deadlines. Turns out, it was only because he was really bad at estimating time. Once I learned that, and started handling some of his estimates for him, he was the best programmer on paper too."

...was most probably me =D

</comment></comment><comment><USER10> The best advice I could give is, whenever someone you manage brings you a problem, resist taking it away and solving it for them. Instead, give them some pointers on how they might solve it, but leave ownership of the solution with them. This is hard to do consistently, particularly when it would take you less time to do the work yourself, but the long-term effect is that you grow a team of self-sufficient people, who only bring you problems when they have tried hard to solve them themselves and genuinely need your help. This in turn means your time is freed up to work on the most important things.

<comment><USER11> This is very important imho - the temptation to just do it yourself is for me personally a hard thing to resist, but you will definitely strengthen your team this way and gain more respect from your developers. You obviously want to be there for them for any help and advice, but allow them to be the ones to solve it in the end.

</comment></comment><comment><USER12> Congratulations on the new job!

It sounds like you've already identified your weaknesses, and they are EXTREMELY COMMON - especially for really great engineers.

You used the word entrust, and this is key. It demonstrates that you have a great sense of ownership over the work, and feel personally responsible for the team's output. This is great, but now that you are the team leader and not the team itself, you need to get three additional ideas burned into your brain.

1: The members of your team are working with you toward a common goal, but they are not performing brain surgery on your first-born child. A little imperfection and inefficiency is OK. In fact, it's good business.

2: It is your job to set that common goal - which must be based on a business goal - and get the team to buy into it. Getting buy-in is, ironically, more a function of how well the individuals on your team believe you hear their opinions than how well they hear yours, so this is a great opportunity to practice your listening skills. But once you are all focused on the goal, the fact that someone solved a problem differently or more slowly than you would have will bother you less, because you will know you were doing other important stuff at the time and together you got closer to the goal than you would have alone.

3: Innovation means trying things and learning from them. The more people on your team try things, the more you all get to learn, so give them the space to try and celebrate the process as a team. Yes, sometimes that means people will try things you already know won't work, but sometimes you will learn a better way, or fail in a new way that leads to a new success. None of it will be a waste of time.

Finally, remember that these apply to your own performance on the team as well. Allow yourself the time to experiment and learn as a manager. Listening, delegating, and coaching are all learnable skills that require practice more than study, so just work at it and know that you'll get better at it.

</comment><comment><USER13> Agile Coaching helped quite a lot (even if you don't use Agile)[1].

A CTO of a very successful startup on the valley recommended me _Difficult Conversations_ [2].

As long as you remember that empowering other people to do great work is very valuable in itself (as it is a multiplier), you can motivate yourself into getting to understand this side of software development.

It is not only important for tech leads, but for CTOs, and open source project leads.

Good luck on your new job!

[1] <http://pragprog.com/book/sdcoach/agile-coaching>

[2] [http://www.amazon.com/Difficult-Conversations-Discuss- What-M...](http://www.amazon.com/Difficult-Conversations-Discuss-What- Matters/dp/0143118447)

</comment><comment><USER14> I generally think of it this way: a manager tells you what you _have_ to do. A tech lead tells you what you'd be stupid not to do. You won't have much formal authority. At the same time, you hopefully won't _be under_ much formal authority if you chose the right startup.

At the same time, you earn a significant amount of "political capital". People will probably give you a certain amount of deference. And you earn the unique benefit of having a unique perspective on something.

Don't think this can't all be taken away from you, because it can, either due to political or technical considerations. You can get marginalized by someone with an agenda, or you can lose the respect of your peers with a few wrong decisions.

The good news is that you really don't need great leadership or people skills. You just need to convince people that the benefit of having worked with you is greater than the cost of having to put up with you. People are willing to forgive the occasional foot-in-mouth incident or the occasional screw up. You just have to make sure people know what benefits you're providing them in return. And having been objectively right or gotten great results will more than make up for having _accidentally_ hurt a couple of feelings in the process.

</comment><comment><USER15> Congratulations on becoming the lead. You already got some excellent advise in this thread.

I found some good advice about managing and leading teams in books:

"The Wisdom of Teams: Creating the High-Performance Organization" by Jon R. Katzenbach, Douglas K. Smith

"Leading at the Edge : Leadership Lessons from the Extraordinary Saga of Shackleton's Antarctic Expedition" by Dennis N. T. Perkins, Margaret P. Holtman, Paul R. Kessler, Catherine McCarthy.

Few suggestions from personal experiences:

About not delegating, getting your hands dirty can play to your benefit if positioned right as trying to understand what team members goes through in their activities so that you can make better decisions that are in best interests of team members.

Consider your team lead role as mentoring role and not as a "manager" role. Allow people to make mistakes and do lesson learnt type sessions.

Depending on the size of team, have lunch/ informal gathering as a team and also meet with individual team members informally at regular basis.

Watch patterns and signs in how team behaves around you. If they are quiet around you or always agreeing with you, you have a problem.

</comment><comment><USER16> Some of the comments below are a bit scary to me, it seems everyone things architect = manager and I work in a company where this is also the prevailing thought and I just can't agree with this line of thinking. There are a lot of nuances to developing a complex application and the longer someone gets away from coding on a daily basis the more they forget these things, they forget how to "think like a programmer", they overly abstract things and trivialize things. I can't help but realize that the "architects" who I have dealt with who no longer write code always seem to be stuck in the past, they want to use older libraries, patterns, etc that they used back when they were programming even if the prevailing wisdom of the platform currently differs. I guess the only advice is to be aware of this and don't become like this, you still should be at the code level, at least part of the time, if you are truly an architect and not just a manager.

</comment><comment><USER17> Accept that being a lead is going to be challenging. That whatever tasks you have taken on for yourself, you may or may not get to them when you want to. Accept that you will be the bridge between upper management and the technical folks and that you will be dealing with any number of issues.

Also, keep in mind that there are lots of resources out there about how to lead people and be a better leader. Look to the Harvard Business Review ( <http://hbr.org> ) for some good resources on how to be a better leader.

At the end of the day, as a lead, there is a process that you can follow to help you along. The process includes the following: 1) Meet with your team and work out what tasks are assigned, follow up with each team member and confirm that they understand the assignment by asking them to describe to you what they think they are doing, follow up with each team member on their assignment and measure their progress, and finally, check in with them to review their work and let them know when they are done or have completed their assignment - then start again. Use this process no matter how small or big the assignment is.

Some folks use an agile like approach to management of projects and one of the nice things out of this world is SCRUM and the concept of daily stand up meetings. One of the things I would recommend is to get into the rhythm of meeting with your team for about 15 minutes every day to check progress, see what they have accomplished and see what they are working on for the next day and to see if there are any things keeping them from meeting their goals. If you ever hear a complaint, that is a red flag and try to use whatever resources you have to remove those obstacles.

At the end of the day, you only have so much time and energy. Do the best you can and never loose your cool no matter what the situation is.

Best wishes and a great new year!

</comment><comment><USER18> Do you like your team members? If not, find out why and find a reason to like them. Once you develop that basis to like your team members, everything else will fall in to place. You will take interest in their activities, not just in terms of getting your work done, but in terms of what they are trying to achieve.

Talk to your team members on an individual basis frequently and in an informal setting - people are much more open in an informal setting. Keep these meetings to 5 mins. If there are more topics than can be covered in 5 mins, increase the frequency of meetings, not the length.

Never do your team member's work. Help them in every way for them to do their work, but just don't do it for them.

(Break every rule / advice that people are giving out. Finding what works for you is one of best parts of management)

</comment><comment><USER19> The fact that you're even asking how to be good at this is a really good sign. I wish some of the folks that I've worked under in the past would have done the same. There's lots of good advice in this thread.

My advice is to find a way to handle the pressure from above without letting it affect how you treat your team. Technical teams are built on a tremendous amount of trust and understanding.

If you're constantly getting hammered on by your non-technical boss, try not to pass the buck and hammer your team in turn. You may find yourself in very combative situations with the nontechnical leadership, and you certainly wouldn't want your teammates to feel the same way about you. That makes for a very ugly environment, and most smart people won't stick around for too long if that happens.

</comment><comment><USER20> Set up weekly 1:1 meetings. Never miss them. And whenever possible, do the meetings outside, even if it is just taking a walk.

<comment><USER21> I came here to say exactly the same thing... so, here's my other piece of advice: Think about very good managers that you've had; what was it that made them good managers? Try to emulate that (for me it was the weekly 1:1).

</comment></comment><comment><USER21> Don't express appreciation, show appreciation. What do I mean?

Express appreciation: Hi Jane, I really appreciate that you worked until midnight to get rid of that bug.

Show appreciation: Hi Jane, I looked through the code - and you've really improved it by replacing that buggy lookup with a hash function.

Anybody can do the first and it does not take time or effort. The second shows that you've taken some interest and taken the trouble to understand what they've done.

</comment><comment><USER22> An MBA probably won't help you and may even make it worse.

The first step is recognizing there's a problem and seek help, which you've done and I congratulate you for that. I think you just have to be more patient and humble.

Even if you think you're the smartest person in the company, you have to learn that others can bring something to the table also. Just setup what the goals are of the meeting at the start then give people a chance to speak and withhold your own opinion until after you've heard everyone else talk at the end. Again don't try to interrupt too much and give everyone a chance to voice their opinion, and use it as an opportunity to try to learn something from others (ie. respect that others have something to teach you as well). And sometimes you'd be surprised at learning something you didn't expect or know beforehand that would change what you thought should happen.

</comment><comment><USER23> You might want to simply look into reading some leadership books. _Leadership 101_ [1] is one you can read in probably an afternoon, to get you started. From there John Maxwell as a few more books on Leadership as well.

As I haven't been in a team lead position myself, I'm not sure if any of these books can help you learn how to delegate as that seems something that would take time and practice.

I have however, worked under a few engineer-become-leaders that are simply horrible leaders, and I -wish- they would read a book like this some day and have it click. Your success as a leader can possibly be measured with how successful you are at raising leaders under your wing.

[1] [http://www.amazon.com/Leadership-101-John-C- Maxwell/dp/15964...](http://www.amazon.com/Leadership-101-John-C- Maxwell/dp/1596448318/ref=sr_1_1?ie=UTF8&qid=1325257380&sr=8-1)

</comment><comment><USER24> I tend to be of the mind to learn by doing. As many of the others have mentioned, have conversations with your team members and spend time with them. A common practice is to grab lunch with them. This will help you get to know them and become more comfortable talking and listening to them.

I would also recommend regular work oriented meetings with them. Some may disagree, but I think regular meetings to review work, and go over tasks has a lot of value. You will see when they are finishing up their work and be able to hand off tasks more readily. Also do what you can to get feedback from them on you, and don't take it personally when they are critical and learn from it.

Ultimately there is no one answer and you have to find your own style as well as a style that works for your team. A conscious effort and trial and error will be better than books.

</comment><comment><USER25> Make lists. That's 90% of the job of a manager. Always have an answer to "what should I do next?"

</comment><comment><USER26> Well...I've been in the software engineering biz for a while now and go between being an engineer, an architect, and manager depending on the company and group. I don't have any formal management training and don't even have a post-high school degree. But I love building software (I started writing assembly on an Apple II+ way back when) and working with people and am in a constant state of learning.

The quick answer is that there's no easy path if you want to be good at this. You need to be aware of your natural strengths and weaknesses, and what you've built up over the years to compensate. If you can, find a mentor, or at the very least have regular lunches or coffee with folks with more experience.

It sounds like you are a technical leader with management responsibilities, which is a very tough position. A lead/architect position without management duties usually means that you are involved with all technical decisions in the group but don't have direct reports. When I'm an architect, I expect the majority of my time will be writing code with maybe 30%-40% of my time split between formal meetings and hallway conversations. I will not take an architect position that has no hands on coding - it's a recipe for failure. An architect/lead will need to understand the business and technical needs and help drive things forward so both sides are happy. Look for quick wins here to keep things moving and 80/20 solutions. Also know when to stand your ground on things that you know are wrong - be able to communicate your reasoning for both engineers and non-technical folks. That role will also need to have strong technical vision and the ability to communicate that vision so other engineers will be able to follow the path. Figure out the types of engineers and what they need to get their jobs done - some like diagrams, some like talks, some like code examples, some just need a few lines in an email. Conversely, you'll need to be able to help the business side understand the technical side. You'll also have to know your team and help with things like pushing things through to avoid engineer navel gazing, balancing NIH attitudes, breaking ties on proposed solutions, slotting in engineering driven changes that destabilize things, helping the engineers understand why they can't rewrite a key component of the system without showing the business value, helping the business understand why adding a fifth story to their building won't work because really have a bicycle, etc.

Architects are expected to be "big dawgs" in terms of technical skills, so it's ok to be opinionated and try to out-think others. Your own style will come into play and you need to recognize it and be ok with how you work - <USER2> might be the type who doesn't suffer fools lightly and because you see the solution before anyone else, you just make your vision happen and ram it through. Or maybe you have a high end team and you need to listen to the other ungodly smart people around you and do more consideration. You do need to pay attention to other engineers and business folks, and listen to them.

A good manager requires an addition set of skills. Management is really a career restart because you're really going down a whole new path. The things that got you to the management position aren't the things that will make you a good manager. Being the smartest person in the room does not a good manager make. A good manager creates an environment for others to succeed. A good manager listens a lot and doesn't try to come up with the solutions. A good manager recognizes that the right idea will present itself because the team is awesome. Try to come up with as many options at possible decisions points. If a tiebreaker is needed, a manager should be able to argue both sides convincingly and not take sides (unless one side is just flat out wrong, but hopefully it won't come to that). A good manager will let problems and solutions come up from the team. Managers need to be aware that each person is different and adjusts to each person. Depending on the group, they also need to have a slightly more balanced view of the business then an architect. It does require some politiking as well - you shouldn't go into a meeting for a big decision without knowing where people stand ahead of time. Managers also have to deal with the 'kindergarten' issues like ruffled feathers, misunderstandings, bruised egos, etc. You'll need to know when someone is just venting versus needing your action. And people have lives that impact the team as well - people get divorced, have kids, get sick, have people die on them, switch genders, come out of the closet, find Jesus, etc. A good manager makes a personal connection and gets to know each person's story. This lets you figure out where each team member is coming from and then how you can make sure their needs and values are met at work. People are happy when what they want out of life lines up with what the company needs. Managers need to know when someone on the team is causing issues and maybe isn't working out. Letting someone go is tough, but usually it should be obvious to everyone involved that things aren't working out. It also involves bearing bad news to both your team and other teams. Telling the CEO that your team fucked up and caused customer level issues is rough.

Let's see...what else...hiring the wrong person is orders of magnitude more difficult than delaying a hire. Be super picky when hiring, even if the executive staff is pushing you hard to fill those reqs.

Engineers like to solve problems, so presenting things in the form of a problem can be a useful approach.

Even if you have a solution in mind, start from the top and lead people through. Let them come to the same conclusions you did and when they do, them tell them the pros/cons of each decision.

Sometimes you have to be the alpha dog and make a decision that someone heartily disagrees with - you need to understand their position, be able to echo it, and stay the course.

You cannot take on other's emotional issues - you can be aware and offer help, but you can't internalize them.

Try not to play favorites - this is tough because you'll find people that you connect with easier.

Put yourself out there, let the team get to know you as a person so that connection is better.

You need to keep in mind that you might have to fire anyone on your team at some point, or give them feedback they don't want to hear, etc. So there's a fine line between becoming friends with folks and being their boss.

Have fun with it, I try to keep a sense of play with me because that's part of who I am.

I dunno - that's it for me - this was kind of a lot of stuff without much structure, but I wish you the best of luck. This is a tough change for an engineer but the fact that you're asking these types of questions shows that you care and are willing to change to be better.

<comment><USER27> This sounds like great advice, and your post would make for a good blog entry.

</comment></comment><comment><USER28> When I first landed this kind of role, I was given a copy of "Peopleware: Productive Projects and Teams ". In some circles it is considered a bit of a bible for this topic.

It's kind of an old book, but then the principles have remained the same. It also means this book isn't then laced with specific methodologies of the day or what not.

Downside is its a tad expensive on paperback, but reasonable on Kindle:

[http://www.amazon.com/Peopleware-Productive-Projects- Teams-S...](http://www.amazon.com/Peopleware-Productive-Projects-Teams- Second/dp/0932633439)

</comment><comment><USER29> One little piece of advice: your priority is giving work to your reports. Avoid at all costs that they're idle. To achieve that, you must plan to be idle yourself half of the time, so you can attend them when they need it (they will.)

The other half of the time is to explain your bosses what your team is doing, so if you're thinking of programming yourself, think again.

Edit: for both halves you absolutely need to know at all times what everybody's doing, how they progress, what obstacles they're finding.

</comment><comment><USER30> For me, I was only able to learn through experience, but hopefully my experiences can help you avoid my mistakes. My first lead opportunity at my first company was about 2 years in. It was a 12 or so person company, and all positions were flat except for the owner. When I was promoted, I considered my new main goal in life was to improve efficiency. While true to a point, I decided that the way I was to improve efficiency was to start tracking every piece of work performed. I created elaborate tools to allow everyone to check- in their time, and built amazing executive reports to interpret this data. However, efficiency (or rather actual work being done) was dropping. Identifying this as a failure on the team's part, over the period of a year, I implemented a series of changes ranging from good cop stuff (take the guys out for team-building) to bad cop stuff (threaten pay-cuts, firings etc..)

Later at a new company, the opportunity presented itself, and I was sure I had figured it out this time. Around this same time, I was really into design patterns and diagramming. In fact, I felt as though every problem in life could be distilled down to a pattern. Every member of my team could fit into nice little diagrams as boxes, and the work would get done like magic. A designer was a designer, and programmer was a programmer. Everyone and everything was interchangeable. We could outsource work when we needed it, and get rid of people when we didn't.

A bit later at a different company, I was able to give leading a third try. Around this time, I was reading a lot of joelonsoftware, and randsinrepose. Instead of implementing anything, I decided to just try to eliminate obstacles for my team. I started weekly 1 on 1 meetings with my guys, allowing them to talk about anything they wanted for as long as needed. Lastly, I just tried to be the guy that I wanted my guys to be. I made a conscious effort to keep my morale up, not let things get to me, and lead by example.

Looking back, I see that in the first two, I was trying to implement things that motivated me. I love analytics and treating tasks as games. I love seeing charts go upward. However, management is about your people, not you. People are emotional and complex. This sounds pretty cliche as I write it, but try to improve yourself as a person, encourage that in your team, and the productivity / efficiency / whatever will take care of itself.

Good luck!

</comment><comment><USER31> Leadership revolves around having respect for your colleagues and believing in them. This component is very similar to an ability to maintain healthy relationships with family and friends.

Don't be just another software developer destined for a career in middle management. Spend quality time with your team and get to know them as people. Find out where they excel and assign responsibilities accordingly. The listening part will then come naturally.

</comment><comment><USER32> I found this book very helpful in understanding of my role as manager: [http://www.amazon.de/F%C3%BChren-Leisten-Leben-Wirksames- Man...](http://www.amazon.de/F%C3%BChren-Leisten-Leben-Wirksames- Management/dp/3593382318/ref=sr_1_1?ie=UTF8&qid=1325257860&sr=8-1) (German). Malik's style is probably not to everyones liking - I enjoy it, though.

</comment><comment><USER33> manager-tools has a nice website of podcasts about some basics of management. I find these guys to be really sharp. Here is a link to their basics page: <http://manager-tools.com/manager-tools-basics>

one on ones, coaching, feedback and delegation. They make a great logical case delegation.

</comment><comment><USER34> Hard to answer but: 1\. know the design better then anyone else. 2\. Be ready with any question that may come up. 3\. Know what your guys do at any time. 4\. Plan a good gantt. 5\. Be a friend with your team until it comes to work decisions. 6\. Backup your team against anyone outside the team.

</comment><comment><USER35> _I'm having a hard time being a good listener_

Fix this first. It's a prerequisite for leadership.

<comment><AUTHOR> Hard but honest... any specific advice on how to do it?

<comment><USER36> I hate to say it, my friend, but learning to listen is largely about changing your attitude towards the people around you. It is very difficult to listen when you perceive that you're miles above everyone around you. Consequently, the first step is to learn to see how wonderful, competent and intelligent every single person around you is. If the people who surround you are (in actuality) neither competent, intelligent or even remotely wonderful, run (don't walk) away and find new people!!! :)

Once you have built a genuine interest in the people around you, good listening skills naturally develop. When you're interested in the people around you, you will hang on their words, ask probing questions and reflect back what you heard to make sure that you understood it.

If you can't engender a natural interest in the people you surround yourself with, you can fake an interest. To do so, I recommend getting in the habit of repeating back things that you hear, nodding in agreement when the person says something you agree with, not interrupting when they say something you disagree with, and asking probing questions when you don't understand/agree with something.

Have you ever considered Toastmasters? It sounds silly to join a public speaking group to become a better listener, but I can't tell you how much Toastmasters helped me!

</comment></comment></comment><comment><USER37> You don't need an MBA. You already know what you need to do. For every conversation you have, concentrate on one thing: being an active listener. Focus on that like you would focus on a technical problem.

</comment><comment><USER38> [http://www.jamesaltucher.com/2010/11/how-to-exploit-your- emp...](http://www.jamesaltucher.com/2010/11/how-to-exploit-your-employer/)

</comment><comment><USER39> I'd recommend reading "Being Geek" by rands. Its great.

<http://beinggeek.com/>

</comment><comment><USER40> Lead by asking questions. It will force you to change your style, and it will grow others at the same time.

</comment><comment><USER41> Congratulation first.

Managing people is easy—but being a manager is not about managing people.

You have to be aware that managing is not as satisfying as coding and your goals have totally changed from now on.

\- Learn to listen—that's so crucial—they're tons of techniques to get a better listener. Listening can be boring but these techniques enable you to listen hours (even with a smile on your face) without getting bored. It's so damn important that I stress it again: you should listen 95% and talk just 5% (from now on meetings aren't fun or a relaxing break, they become hard, boring work).

\- Always 1-to-1 meetings—always. Every meeting with more than two people is worthless, try to avoid them, if you can't just keep them short and full of small-talk, fun and non-sense but without decisions. Harsh words, but leading is not anymore about cookie-cutting talks with colleagues. That's one of the big downsides of leading.

\- Don't focus too much on your staff—look that they are happy and motivated (most important) and they have always challenging work, that's it. Don't try to be all the time around them—if they need help be there. Don't change your communication, just be yourself, but don't think they are your friends. Focus now on next steps within the company—you are now doing first steps in management and your work changed from working yourself to networking, to give and take and last but not least to power politics (if your startup is >100 employees). Look that you spend more time with peers from other departments and higher level peers in your company. If you can't progress or your company sucks in less than 12 months, look that you spend a lot time outside your company (there're lots of ways) and move on.

\- Don't use tactics or manipulative techniques even if you are good in it. People always feels there's something wrong. Be yourself but keep distance.

\- Get a mentor or coach with leadership experience in highly volatile environments, preferably outside the company

\- Because working oneself is still most fun, look that you keep coding on private projects, even while in office (there're lots of ways). That's good for your own motivation and keeps your coding skills fresh. Otherwise you burnout after 6 months of all the meetings, mails and bullshit. That's important because from now on you will slowly loose close relationships within the corporation, upcoming relations are different, more political and it's important to stay grounded, meet lot of people (again leave your company often, go to meetups, because there you can just be yourself and that makes you happy; if you don't do this you'll quickly degenerate and get isolated because the working contacts are less and less true relationships). To officially code yourself is not an option anymore (which is sad) because after the first bigger mistake your management will tell your that you are not able to lead your folks when they see you coding with them (which would be better but non-technical management and c-level just don't get it)

These are all only very small hints without giving you the big picture which would take more time and there is no book giving a really deep understanding (I've seen many books before I had my first leadership position, none of them is written by real leaders).

If you want more advice: renmarksky at live.com

<comment><USER42> I like your advice, except for the insistence on 1:1 meetings only. When there's a dispute on the team, the best option is often to grab a meeting room with a whiteboard and hash it out right then and there. Trying to mediate via 1:1 meetings or e-mail threads often just lets the dispute fester and poisons interpersonal relationships among team members.

<comment><USER41> Meetings aren't easy. Sure it can help to grab a room, gather and talk and calm down but an existing dispute can also further escalate in a larger meeting—it's gambling. One does always loose after a dispute (in his point of view) and that's much harder to accept in front of many than in front of one. If two have already a dispute, sure then you should talk with them both at the same time and act as a moderator. But still it's a very complex dynamic process which is harder to control with more participants.

Moreover, you can often clear/avoid a dispute when you had lots of 1-to-1-meetings beforehand where you got a good understanding of peoples thoughts, fears, etc.

</comment></comment></comment><comment><USER43> Firstly Congratulations,

Now coming to how might probably go about this is awesome opportunity. Remember a very important thing about software today. Its extremely difficult to do anything big without a team these days. Even giants need teams. There fore I will first start out with both the Technical and Managerial areas you need to be aware of.

Technical:

As a manager, you might not have to know and understand each and every line of code that is out there in your code base. But you definitely need to understand enough technical details to consciously solve problems, take decisions and assign and referee things among team mates when needed. This means you have to on a day to day basis keep track of the developments. To me this can addressed by separately planning a part of the day, this can achieved in a stand up or status call, where everybody quickly reports three things "What they did yesterday", "What they are doing today" and "blockers". Your job is to first get sufficient perspective and context about he work your team is doing, incrementally know their progress every day and remove any thing that is coming in their way of achieving those tasks.

In turn you will have your own updates. Its not difficult with a little discipline. You can take strides.

Management:

Here, you need to take a little care. Planning, Prioritizing, tracking and course correction are crucial. They say, a true appraisal in any company is when the junior and manager know exactly where they both stand. A good appraisal has no surprises.

Talk to your team mates and be friendly with them as much as you can. Develop their trust as a friend. Most people will do work for your just out of politeness and courtesy. Never use provocation or threat as a means of motivation(Often geeks make this mistake). Try to take things as easy as you can, but be serious and stand up and make the person understand the seriousness of their mistakes. Stop there, no further. Basically they must respect you.

Trust them, or at least make them feel you trust them. Even if you don't internally. The reason being once they realize you don't trust them, they will loose all respect for you. They will fail to replicate the same feeling back. Work, productivity will dry out and ultimately lead to a separation.

No invisible assumptions. Neither assume, nor allow others to assume. Make plans, and prioritize, execute, track and course correct in iterations frequently.

Your job must be to inculcate this agile discipline, with as little distractions, more trust, friendship, higher productivity and aligned towards goals.

P.S :

I am not a manager, But I would like my manager to be like the one I mentioned. I admire some of my managers who truly were like that.

</comment><comment><USER44> Here's a good tip. When you write something find the ratio of the number of times you refer to yourself in what you wrote to the number of sentences. It's a good indicator that others will find you self obsessed. Well experienced leaders I've known almost never referred to themselves except in telling a joke.</comment>


Gov. Brown Signs CalECPA, Requiring Police to Get a Warrant for Your Data - <AUTHOR> https://www.eff.org/deeplinks/2015/10/victory-california-gov-brown-signs-calecpa-requiring-police-get-warrant-accessing <comment><USER2> Maine and Utah have also implemented these protections. This movement is being called the Digital 4th Amendment and has at website at [http://www.digital4th.org](http://www.digital4th.org)

</comment><comment><USER3> This needs to be a Federal law, but that can't possibly happen with our dysfunctional government. I'm glad to see the States at least taking action.

<comment><USER4> Isn't that because according to some in the Senate the Internet is just a series of pipes? Wish I was saying this mode in jest.

[https://en.m.wikipedia.org/wiki/Series_of_tubes](https://en.m.wikipedia.org/wiki/Series_of_tubes)

<comment><USER5> But Ted Stevens got the mental model right. The internet is _supposed_ to be a series of tubes, the tube is _supposed_ not to care what flows through it. This approach has been very good for innovation, very much unlike the walled gardens we are seeing today.

<comment><USER6> This. When talking to extremely non-technical people (or being one yourself), who are we to begrudge a few abstractions?

Isn't the important thing that it's a appropriate and functional abstraction in the problem space in which it's deployed?

</comment></comment></comment></comment><comment><USER7> So the tools, infrastructure and contacts are all there for police to hit a button / make a phone call and get your private data.

Why bother getting a warrant if you can open your laptop and have your suspicions validated in five minutes?

Access shouldn't be in the hands of local departments with little to no accountability. I'd go as far to say that access shouldn't be made available at all, but it's almost 2016 and that isn't changing.

[http://theantimedia.org/local-sheriffs-dept-used-stingray- su...](http://theantimedia.org/local-sheriffs-dept-used-stingray-surveillance- more-than-300-times-without-a-warrant/)

[http://www.wired.com/2015/04/ny-cops-used-stingray-spy- tool-...](http://www.wired.com/2015/04/ny-cops-used-stingray-spy- tool-46-times-without-warrant/)

</comment><comment><USER8> > These protections apply not only to your devices, but to online services > that store your data.

I assume this is referring to giving a warrant to the company holding my data for me. I would like this to go a step beyond that and require law enforcement to sign a warrant that it presents to _me_ , since it's _my data_.

</comment><comment><USER9> California law will not trump any law at the federal level. This will only affect the local police and not the FBI, NSA or anyone else who wants your data. Of course if they happen to share it with the police just for grins...

<comment><USER10> The Justice Department is already requiring warrants for federal agents using stingrays. That decision didn't affect local/state departments, but AFAICT everything in California is covered under one or the other now.

[https://www.washingtonpost.com/world/national- security/justi...](https://www.washingtonpost.com/world/national- security/justice-department-agencies-will-have-to-obtain-warrant-before-using- cellphone-surveillance- technology/2015/09/03/08e44b70-5255-11e5-933e-7d06c647a395_story.html)

</comment></comment><comment><USER11> It's good to see California's government functioning well.

</comment><comment><USER12> Cool. Jerry Brown is a good leader.</comment>