Is quantum mechanics messing with your memory? - <AUTHOR> http://www.guardian.co.uk/science/blog/2009/aug/26/entropy-time-arrow-quantum-mechanics

<comment><USER2> Here's my understanding of the Maccone paper. Edit: I only skimmed it.

Super-condensed QM intro: In the _formalism_ of quantum mechanics, the dynamics of physical processes are represented by unitary operators. If Y(0) is the state of the system at t=0, then the dynamics (change, movement) of the system is represented by a unitary operator U(t), such that the state of the system at time t is Y(t)=U(t)Y(0). The technical term unitary roughly means that it is time-reversible: there exists the inverse of U(t) meaning that the inverse physical process can also occur (the hidden assumption is that there is a 1-1 correspondence between operators in the formalism and actual physical processes). The problem is, if everything is time-reversible, why don't we see glasses unbreaking or gas that came in to fill the room through a little hole finding its way out again?

Measurements in QM are _not_ unitary. If you measure something, you can't undo it. Measurements are in this sense an "add-on" to QM.

The following argument probably pre-dates the Maccone paper: Take a room which contains a quantum system Q and an observer O. The observer makes measurements on Q, which are not unitary, so he sees time irreversible processes. Now take a superobserver O', who is outside the room. To him, the room (Q and O together) make up a quantum mechanical system Q', which may be described in a unitary way. This means that the superobserver O' can argue that even though the observer O only sees time irreversible processes, the inverse process can in fact occur (glass unbreaking), but they reverse the observer O itself (who is part of Q'), meaning that he "forgets" what he measured, his ink "disappears" from his notebook, and so on.

Maccone's contribution seems to be that he identifies O measuring Q with O and Q becoming quantum entangled and provides some formalism.

Substitute "time-irreversible" for "entropy increasing" for trendiness (eg. to pick up girls in a bar =)).

<comment><USER3> I skimmed the paper the other day, but still didn't quite understand what he was on about.

In particular, I didn't understand why he feels the need to invoke quantum mechanics at all. Thermodynamic systems don't flow backwards from high-entropy to low-entropy states simply because there are far more high-entopy states than there are low-entropy states.

Or to put it another way, what does Maccone think would happen in a purely classical universe? Would not entropy still increase there?

I find that discussing thermodynamics works terribly for picking up girls in bars, but maybe I just go to the wrong bars.

<comment><USER2> Susskind answered a similar question during his stat. phys. lectures which you can watch on iTunes.

Somebody asked the following question: given that entropy is the volume of the system in phase space and Liouville's Theorem (of classical physics) tells us that the volume in phase space is conserved, how come entropy increases? His answer: Liouville's Theorem holds, the volume stays the same, but the blob representing the system (the system's microstates) spreads out in a fractal way in phase space, increasing the "coarse-grained" phase volume / entropy. Then, a "you can't set the initial conditions infinitely precisely" / "you can't measure inifinitally presicely" type argument is invoked to say that in terms of real-life reversibility the course-grained volume is what matters, so entropy has increased despite Liouville.

Explained here: [http://www.google.com/url?sa=t&source=web&ct=res&...](http://www.google.com/url?sa=t&source=web&ct=res&cd=21&url=http%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DR- jQ4I0VkdoC%26pg%3DPA70%26lpg%3DPA70%26dq%3Dliouville%2Btheorem%2Bentropy%26source%3Dbl%26ots%3DRKI8zXfw-0%26sig%3DtZOa77uJCTs8-XibeaJWf3qhPKk%26hl%3Den%26ei%3DrquWSvulI47Y-QatkeTQCQ%26sa%3DX%26oi%3Dbook_result%26ct%3Dresult%26resnum%3D1&ei=rquWSvulI47Y-QatkeTQCQ&usg=AFQjCNGLutp18ilwZw- _ZISvOG_oxCbISw&sig2=mk0O2_FIpPZ3etOpTas28g)

</comment></comment></comment><comment><USER4> I don't buy it for a simple reason. It is easy to look around the macro environment and see plenty of reasons why entropy has a long way to increase. For instance for several billion more years the Earth should be receiving energy from the Sun and radiating it off into outer space, which creates a sustained low entropy situation enabling something we call "life" to exist. Therefore the question of the arrow of time seems to me to be explaining why the macro environment looks that way.

I'm not sure where I heard it, but one idea that I like is that it ties to the Big Bang and the expansion of the universe. Most people don't realize how complicated conservation laws get in general relativity. For instance it is a matter of opinion whether or not energy is conserved! (See [http://www.math.ucr.edu/home/baez/physics/Relativity/GR/ener...](http://www.math.ucr.edu/home/baez/physics/Relativity/GR/energy_gr.html) for details.) In particular suppose a photon sets out on a long journey, gets red shifted by the expansion of the universe, and consequently loses energy. What happened to the energy of the photon?

This question is highly relevant to the issue of entropy. Current theory says that we had a very hot and almost uniform universe, which then expanded rapidly. As it expanded any clumps that formed stayed hot, while the space between them cooled off, thereby leading to an increased thermodynamic non- equilibrium. Worse yet, local gravity pulled the clumps together resulting in interesting things like stars, which further increased the amount of non- equilibrium stuff going on.

Of course this pushes the question of the arrow of the time down to cosmology and general relativity. But given that physicists debate whether conservation of energy makes sense in general relativity, I'm fairly comfortable with accepting that the laws of thermodynamics are on even shakier ground there. Which makes the physical asymmetry seem not so bad to me.

</comment><comment><USER5> I'm not convinced that this is a really _great_ article. But it may be as good as it's reasonable to expect a one-page popular article on this subject to be.

It is incredibly difficult to write an article like this. You can't assume that your audience knows what entanglement is. You can't assume that they know what entropy is. And even if you thoroughly understand those two things it isn't exactly clear what this research is trying to say. It reads like something that is being badly translated out of the original mathematics.

</comment><comment><USER6> Isn't memory just a couple of changed atoms? So erasing memory would be equivalent to making atom configurations unchanged. But if atom configurations don't change, entropy doesn't change. So the whole theory seems absurd.

(Disclaimer: I don't really know QM very well)

</comment><comment><USER7> You mean ARE quantum mechanics messing with your memory, and those quantum mechanics should go back to fixing quantum cars!

</comment><comment><USER8> _When you observe any system, according to Maccone, you enter into a "quantum entanglement" with it._

That's a nice theoretical claim, but in practice it is just plain false. Two macroscopic objects, like a human and a cup of coffee, at room temperature, entangled? Give me a break. We have to go trough a hell of a lot of trouble to create entangled pairs of photons to do experiments with. Interactions with the environment break the entanglement, which is exactly what we are doing all the time.

 _Maccone's solution is to suggest that in fact entropy-decreasing events occur all the time_

Of course they do. The point is those fluctuation in the 'wrong' direction last an extremely short period of time. We have no trouble observing temporary decreases in entropy: the 2nd law of thermodynamics holds over macroscopic periods of time and that has been verified experimentally. Laplace's daemon doesn't exist, but he can deceive you for a nanosecond.

The problem with these damned brilliant mathematician-physicists is that they really loose touch with the boundary conditions imposed by physical reality.

<comment><USER3> _That's a nice theoretical claim, but in practice it is just plain false. Two macroscopic objects, like a human and a cup of coffee, at room temperature, entangled? Give me a break._

That idea is pretty common in (so-called) many-worlds interpretations. In such interpretations, the wavefunction never collapses: the "collapse" of the wavefunction is just the observer becoming entangled with the system. This, of course, has all sorts of disturbing implications, but arguably still makes a lot more sense than any other interpretation.

</comment></comment><comment><USER9> (I realize this article is very light but its is an interesting point of departure...)

So are all the 'positive thinkers' correct? Is life but a giant breadth-first search where we strive for some optimum to only remember the last path we took?

I'd be willing to give up some memories to bring Dad back.

[Pathos apparently gets downmodded - interesting].

<comment><USER10> The answer is no.

The downmodding is, I think, because people are sick of metaphysical misinterpretations of QM.</comment></comment>


₹Query (jQuery for India) - <AUTHOR> https://razorpay.com/rquery/ <comment><USER2> I get that this is an April 1st joke, but this bit actually hit home:

> We call it, "R-Query". Since demonetisation and US presidential elections, > we knew that ₹ is the future and we can't rely on $ anymore.

</comment><comment><USER3> In the same vein, Skala was announced yesterday: [http://scala- lang.org/blog/2017/04/01/announcing-skala.html](http://scala- lang.org/blog/2017/04/01/announcing-skala.html)

<comment><USER4> One of the guys in our community actually fell for it.

</comment></comment><comment><USER5> [https://github.com/jquery/jquery/compare/master...razorpay:m...](https://github.com/jquery/jquery/compare/master...razorpay:master)

</comment><comment><USER6> I can't wait for this to show up in a job posting.

* minimum 2 years experience with ₹Query

You know it's going to happen somewhere.

</comment><comment><USER7> > chaach, aloo prantha, sarso da saag, lehsun ki chutney and much more. Burrp.

Now i'm hungry

</comment><comment><USER8> Now I want €('p').addClass('euro-rules');

<comment><USER9> €('greece, spain, portugal, france').hide();

<comment><USER2> ₺.Deferred.reject()

</comment></comment></comment><comment><USER10> > Since demonetisation and US presidential elections, we knew that ₹ is the > future and we can't rely on $ anymore.

Given the global currency composition of official foreign exchange reserves, you have little choice in the matter.

</comment><comment><USER11> LOL, nice stuff</comment>


Ask HN: How to Be a Good Technical Lead? - <AUTHOR> Dear HN,
You've been a source of great information before, and I'm sure I won't be disappointed by your advice.
I worked as a Software Developer all my career (more than 15 years now), but now I'm interviewing for a Technical Lead position. I have almost two weeks before the interview.
I'm interested in resources and advice on how to be a good Tech Lead, regarding both technology and people skills. Of course I've seen and taken note on how other leads work, but still feels like a big step for me.
The development environment is Microsoft.NET. The main product is a complex software. The main goal would be to develop it so that it is "loosely" built, split into separate modules so that each one can be modified without touching the others. <comment><USER4> Here are three rules I've followed:

1) If there's an exciting fun task and a messy unpleasant task, assign the fun task to someone else and do the unpleasant task yourself.

2) If someone on your team wants to ask you a question, always make yourself available and absolutely pretend that you don't mind being interrupted. But if you need to ask someone on your team a question, always ask first if it is a good time for them to talk and offer to come back later if they are in the middle of something.

3) If someone wants to try an approach that you think is wrong, say: "I'm not sure that's the right approach, because of X, Y, and Z. However, I've been wrong before, so I might be wrong about this, too. How long will it take you to research this approach and see if it works out?" If you're working on a tight schedule, this may not be practical, but if you want to develop good engineers in the long run, this can be beneficial for everyone.

<comment><USER5> How do you avoid burnout when you're being so self-sacrificial? Seems like it'd be a big risk.

<comment><USER4> Your satisfaction changes from being happy that you've polished some nice bit of code to being happy that you've shipped a product and successfully run a group, and gained the admiration of the people on your team and in your company. Competence is it's own reward.

I learned those rules from observing the behavior of group leaders I've worked with/for. There have been a few times (over many years) when I've thought to myself, "My boss is fantastic! I am so amazingly lucky to be working for this person!!" When that happens, I've asked myself, how does he/she do it? And tried to figure out the answer.

<comment><USER6> Well, if you keep working on shitty tasks (because you assign them to yourself) and keep being interrupted, only for your product to depend on the hazards of the market, you will get burned at some point if what you ship fails for reasons that don't depend on you or the team and people leave as a result.

I honestly hope it will not happen because you seem like a great Lead, but you can't say this scenario is not a possibility.

<comment><USER7> Burnout's likely whenever you work really hard on a product that nobody uses, regardless of what your role at the company was. It sucks to sacrifice hard for something that doesn't pan out.

The solution to that isn't to only work on the stuff that pleases you, though. It's to only work for companies that have traction or at least demonstrated consumer demand. It's the founders' job to validate that there's a reason for the company to exist; make sure they've actually done their job before you entrust them with yours.

</comment></comment></comment></comment></comment><comment><USER8> \- you're going to be part of a lot of meetings, email list etc... Make sure you flow information down to your team, every day.

\- your main job will be to:

        - unblock your tam members

        - bring them back on track

\- consensus is great, but sometimes it doesn't work. Know when you need to make a decision even if not popular.

\- praise publicly, criticize in private

\- give people a chance (give warnings)

<comment><USER9> Also:

      - Be explicit about your expectations for each of the team members. This is a
        discussion, not a declaration.

      - Give feedback early and often, both constructive and kudos.

      - Your first priority is the productivity of your team, not your individual
        productivity. This means taking the time to help team members that are
        struggling, even at the expense of closing out your own stories on time.

      - Don't be afraid to be vulnerable, admit your own failings or tell your team
        that you don't know. Allowing your team to see the decision making process
        when you go through it can be very valuable and is much better than just being
        the guy who has an answer to everything. As a plus, showing your own
        vulnerability will lead to your team showing their vulnerability more readily.

      - Even if you've got the answer, sometimes it makes sense to let your team make
        the decision. There are often many right answers. Remember, your job isn't to
        choose a right answer, it's to ensure that the team doesn't choose a wrong
        answer.

<comment><USER10> > Even if you've got the answer, sometimes it makes sense to let your team > make the decision. There are often many right answers. Remember, your job > isn't to choose a right answer, it's to ensure that the team doesn't choose > a wrong answer.

Couldn't agree more. Allowing the team to own decisions as a group goes a long way toward boosting morale and giving each member a greater sense of pride and ownership. Sometimes people need subtle guidance away from poor choices, but often time, allowing people to explore options on their own-even briefly, they'll often make the right choice in the end.

</comment></comment></comment><comment><USER11> What's a good source on becoming a software dev lead? Here are a few suggestions among the many available:

Brooks' "The Mythical Man Month" is a classic in this space, though I think its emphasis is less on leadership than the difficulties in software project management. And the book is rather dated now.

DeMarco and Lister's "Peopleware: Productive Projects and Teams" is also a classic, and emphasizes interpersonal team dynamics as well as software project management.

Hunt and Thomas's "The Pragmatic Programmer" is highly regarded and traces the progression of a software pro from being led to becoming leader.

Mantle's "Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams" looks intriguing, but I have no firsthand experience with it.

I know agile is a big deal these days, but I can't recommend any books that are specific to doing it well. I'm not really a fan. But in this space, you might take a look at Rich Sheridan's: "Joy Inc: How We Built a Workplace People Love". He runs a small creative agile contracting shop that employs a variety of techniques build and maintain a positive workplace.

In a similar vein is Weinzweig's "A Lapsed Anarchist's Approach to Being a Better Leader". He's the founder of Zingerman's Deli (in Ann Arbor MI) and is a very creative force toward making your workplace constructive and engaging. Not related to software, but full of good ideas.

Weinberg's "Becoming a Technical Leader: An Organic Problem-Solving Approach" is an oldie but goodie in this space, though it doesn't focus on software but tech of all kinds.

Finally, I heartily recommend "Code Complete" as an excellent source on how to program solid/maintainable code, especially if you hope to lead more by example than command.

<comment><USER12> Amazon links for the lazy:

"The Mythical Man Month" \- [http://amzn.com/0201835959](http://amzn.com/0201835959)

"Peopleware: Productive Projects and Team" \- [http://amzn.com/0321934113](http://amzn.com/0321934113)

"The Pragmatic Programmer" \- [http://amzn.com/020161622X](http://amzn.com/020161622X)

"Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams" \- [http://amzn.com/032182203X](http://amzn.com/032182203X)

"Joy Inc: How We Built a Workplace People Love" \- [http://amzn.com/1591845874](http://amzn.com/1591845874)

"A Lapsed Anarchist's Approach to Being a Better Leader" \- [http://amzn.com/0964895692](http://amzn.com/0964895692)

"Becoming a Technical Leader: An Organic Problem-Solving Approach" \- [http://amzn.com/0932633021](http://amzn.com/0932633021)

"Code Complete" \- [http://amzn.com/0735619670](http://amzn.com/0735619670)

<comment><USER13> Thanks for the shortened URLs. Question: I always obtain those by hitting "Share" and then copying the link. Is there a better way?

</comment></comment></comment><comment><USER14> Technology

      1. Know your apps.
      2. Understand your domain.
      3. Understand your technology under the hood.
      4. Have an idea of how you'd approach each project.
      5. Write detailed technical specs for juniors.
      6. Write general technical specs for seniors.

People

       1. Be nice.
       2. Understand you are a resource provider, not a boss.
       3. Get shit done.
       4. Ditch team building gimmicks (see #3 for what's important).
       5. Listen!
       6. Share. Share. Share.
       7. Teach. Teach. Teach.
       8. When you need a bad guy/gal, you're it.
       9. When you need a good guy/gal, your people are it.
      10. Know how to run a project as needed.
      11. Know how to run a meeting as needed.
      12. Don't be bashful.
      13. Don't be (too) stubborn.
      14. Stand your ground with users/bosses.
      15. Have fun & foster an environment for others to too.
      16. Always do the right thing.
      17. Never stop being a programmer.
      18. Never stop loving building stuff.

<comment><USER15> These seem to be terribly vague, e.g.:

      16. Always do the right thing.

Some of these I either misunderstand or contradict each other, e.g.:

       1. Be nice.
       8. When you need a bad guy/gal, you're it.

<comment><USER16> I think number 8 (& nine, because they are heavily related) mean that when higher ups want to blame someone, they should blame you as technical lead (and not individual team members) but when someone needs/is going to be praised make sure it's the team member that deserves it (and not you!). I heavily agree with this.

</comment></comment></comment><comment><USER17> I always recommend the book "Leading Snowflakes" for new technical leads or engineering managers:

      http://leadingsnowflakes.com

It gives very concrete advice, and it explains the people side in terms of skills that may already be familiar to you as an engineer -- for example, to "code review" your management decisions with your teammates.

I'm also a big fan of this video on Autonomy without Chaos, by David Singleton. David is one of the best engineering managers I've worked with, and really exemplifies a style of management that's focused on empowering your team from the bottom up: [https://www.youtube.com/watch?v=RKgZmHhSD9I](https://www.youtube.com/watch?v=RKgZmHhSD9I)

<comment><USER18> It's always interesting to come across a book relevant to me and find that it's basically a step-by-step implementation of Nathan Barry's "Authority" guide to writing a book (I mean that in a positive way, the site is very well made).

</comment></comment><comment><USER19> A good tech lead in my mind is someone with a strong technical vision who has the backbone to see their vision through, but is also very adept at ironing out the myriad issues that fracture teams. It means being an advocate for the best technical solution but compromising with the other teams in the org to meet their needs. It also means being very unpopular as a good technical lead will give commandments from on high even when they're not popular or well liked opinions.

Basically your job will be reducing friction by pissing everyone off. So it's even worse than "if you've done it right, no one will know."

<comment><USER20> In my experience, a good technical lead won't give commandments from on high. A good technical lead will consult and facilitate a discussion and mediate conflict. They will also be directive when the time is right, but only after having listened and weighed the arguments. They will also be able to explain the rationale behind those decisions.

<comment><USER19> I've had your tech lead. They're a weenie and nobody ever congeals around initiatives because they have endless meetings to debate everything all the time. Sometimes you just need to say, "do it this way or find another job." I know that's not a popular idea around the democratized millennial coddling of Silicon Valley, but honestly I'd rather have someone throw down the gavel than sit through another month of research findings meetings before we finally decide git is better than svn. Your person isn't a lead, they're a diplomat.

<comment><USER21> _democratized millennial coddling of Silicon Valley_

What does this even mean?

I'm sorry that you felt your time was wasted in meetings, but you seem to ignore the equally bad outcome of blindly chasing a direction and pissing off all the devs who actually had some foresight.

<comment><USER19> It means what it means. Do you want me to define each word?

It doesn't mean ignoring devs who have foresight; it means looking at the options and picking the best one. Not endlessly debating. We agree on the approach but I think you misread my comment as being a unilateral decision all the way through. I'm just saying you have to be able to make a tough decision without waffling and without all of the facts but with enough conviction that people fall into line with you.

<comment><USER22> > _It means what it means. Do you want me to define each word?_

The most meaning that can be extracted is about your worldview.

The fact is, there are indecisive weenies, and there are over-confident blowhards, but most people fall somewhere in between. When you complain about the culture in general, especially in a get-off-my-lawn manner, it sort of pushes you into the far end of the spectrum where you start to lose credibility with your employees because they realize over time the confidence is not commensurate with the knowledge and expertise.

</comment></comment></comment></comment></comment></comment><comment><USER23> As a tech lead, you're a mixture of manager and lead engineer.

As a manager, you should be clear to represent your team in public in terms of giving everyone credit for success and taking personal responsibility for failure yourself.

As a manager, you need to balance what technical work you assign yourself - <USER2> should be a mixture of interesting projects and valuable scutwork. Don't be the guy who takes all the good work for himself and only delegates work no one wants.

As a lead engineer, the most valuable thing you can do for your team is to focus on helping them start things and finish things. Folks do well in the middle between those two, but most of the wasted time and frustration comes from not knowing how to begin working productively on things or getting lost and not knowing how to wrap them up successfully.

As an architect, be able to quickly change altitude when explaining the behavior of the system or code that you're responsible for. When debugging an issue with a developer, be able to dive deep into the technical details. When explaining a schedule or cost estimate, be able to talk about the system at a high level to the CEO.

</comment><comment><USER24> As a tech lead your job is to support the developers in your team so they are as effective as possible. This means:

1\. You must know the code. Say 'no' to meetings - spend most your time coding 2\. Be honest - When you know the answer say so even if that means someone will have to redo a lot of work. If you don't know the answer, say so (there's no point pretending to be cleverer than you are - you got the job so you deserve it, never try to prove your abilities to others) 3\. Remember your job is to support others so fight for your team's interests even (especially) when unpopular higher up. 4\. Lead by example - take the shit jobs and write awesome code. 5\. Let your team members review your code AND TAKE THEIR ADVICE! 6\. When team members ask you questions attack their problems with the same determination as you would attack your own 7\. To inspire your team members you need to be loyal to them. 8\. To inspire your team members you need to be loyal to the business (often forgotten) 9\. '7' is more important than '8' 10\. Be the best developer you can be (note the word 'be' not 'appear to be')

Ultimately, if your team regularly invite you for beers after work and your boss respects you then you are doing ok. Never, ever assume that 'team lead' is anything more than a specialist role within the team. Your job is to support others. That does not make you more special or important. Respect is earned not given. Being a good team lead is much the same as being a good developer. If you find the job hard then you weren't really a good developer. This is why a lot of companies don't externally recruit tech leads, preferring to recruit from within.

</comment><comment><USER25> On management, it's tough to find good info - some is trite leaderhip strategies. I tend to favor the order writings cause they've stood the test of time. I keep this one saved and re-read it pretty regularly.

[http://philip.greenspun.com/ancient-history/managing- softwar...](http://philip.greenspun.com/ancient-history/managing-software- engineers)

My team is remote, a couple of us been together 10 years and most of us at least 5 years. My managing style I picked up from my mgrs in the company. Pretty hands off. Stars are stars and don't need me meddling - so the general style - let them do their thing.

As far as the average or underperforming employee, I view my job not as trying to "improve people". I need to empower people. As a leader you have some influence on your team, but I think that's a bit overblown. A person's performance is really a result of their mindset.

Their IQ as well. That's important, but some people are just motivated for excellence, others not. I think the key is - understanding where you have opportunities to influence this in your team members' and when not.

One thing I did notice - moving to a mgmt position. It is very temptimg the idea to just get rid of them. It's tough but easier then getting someone truly hopeless to make the necessary effort to improve.

</comment><comment><USER26> Some excellent advice here already, but I'll add a few more. One is to avoid putting development tasks on your own plate that you won't be able to complete. Your time is now likely to be taxed at 50% or more meaning you'll have a lot of demands on your time for meetings and such and so you'll find dev tasks can pile up. Just take on less work for yourself and delegate.

The other one is learning how to wield your authority. You'll now (hopefully) be invited to or least have visibility into leadership meetings, design reviews, contract reviews, road mapping. Make sure you voice opinions in terms of much time tasks will take, which people are needed, what is feasible/infeasible, if you're signing up for a mission impossible. Stop saying things are "hard" or "easy" and instead identify "risks".

Notice that almost nobody in this thread is telling you to work on your technical skills :)

</comment><comment><USER20> I get asked this a fair bit so I started to collect a few of my favourite links together in a blog post: [http://www.andykelk.net/leadership/the-big- list-of-managemen...](http://www.andykelk.net/leadership/the-big-list-of- management-and-leadership-resources)

Specifically to new tech lead roles, I'd recommend "Peopleware" and "Behind Closed Doors"

And a couple of articles specific to your situation: [http://firstround.com/review/this-90-day-plan-turns- engineer...](http://firstround.com/review/this-90-day-plan-turns-engineers- into-remarkable-managers/) and [https://blog.stackexchange.com/2015/08/developer-turned- mana...](https://blog.stackexchange.com/2015/08/developer-turned-manager/)

<comment><AUTHOR> Thanks, added your blog post to favorites. I lived in Melbourne for 12 years, still consider Australia my home.

</comment></comment><comment><USER27> Have a read of these essays [http://97things.oreilly.com/wiki/index.php/97_Things_Every_S...](http://97things.oreilly.com/wiki/index.php/97_Things_Every_Software_Architect_Should_Know_- _The_Book)

Basically you want to become a "Force Multiplier" for your team, thinking a few steps ahead, seeing the big picture, guiding everyone past upcoming road blocks, you need to be able to mentor/help out when it its the fan. And of course you still need to code ;)

A hard job but endlessly fun

</comment><comment><USER28> You will have people who depend on you to allow them to get on with what they do best. You will likely find that you don't write code any more, but have to trust others to do a good job - a better job than you might have done, even. You may not have the time to understand everything they produce. Even so you need to be able to understand the system at a higher level.

As you say, you have some architectural responsibility. This can seem like a large weight on your shoulders if you think that it is all your job. Remember that your developers probably have a huge amount of understanding of the codebase: Don't be afraid to let them guide you, at least partially, in making improvements. There may be others at a similar level who have moved elsewhere in the company who can give you what their plan was for making things better... They might have been where you are but without your remit.

It can be a role where you get to build stuff (with the hands of others), have some power and weight behind decison making, also ever-varied and even fun. It can also be stressful and extremely taxing. Good luck!

</comment><comment><USER29> I also recommend Patrick Kua's 'Talking with Tech Leads' book: [http://blog.fogcreek.com/becoming-a-tech-lead-interview- with...](http://blog.fogcreek.com/becoming-a-tech-lead-interview-with-pat- kua/)

There is also this interview with him here: [http://blog.fogcreek.com/becoming-a-tech-lead-interview- with...](http://blog.fogcreek.com/becoming-a-tech-lead-interview-with-pat- kua/)

</comment><comment><USER30> I'm sure you will get plenty of good advice. My own (limited) experience is that your job is going from a "Individual Contributor" to a "Team Lead". This requires a pretty drastic change in thinking and is not something to overlook, or else things will not end up well. This means that there is going to be a lot of work - much more than you can do by yourself - that's why you have a team to support you. The primary thing I struggled with in the past was delegation. Learning to trust (but verify) your team to complete tasks the way they should be done. I think a lot of people struggle with this and is a primary reason for not doing well in a new role.

Some other quick things that come to mind are: \- Don't be a gatekeeper of information. If you learn something that would be a benefit to the team, make sure they know it and don't have to go through you to get it. That is - <USER3> the team involved.

\- Do take a Crucial Conversations course. You will inevitably have to deal with conflict within the team and knowing how to approach the situation will help significantly.

\- Do have 1-on-1's with your team on a regular basis. You determine how often, but it should be regular and should be a priority for both of you. This is where you will learn about conflicts within the team, about their career path and aspirations, about personal issues that they are dealing with, and will help build trust between the two of you.

Good luck! It's a fun role and comes with it's own challenges, but can be very rewarding!

<comment><USER31> > The primary thing I struggled with in the past was delegation. Learning to > trust (but verify) your team to complete tasks the way they should be done.

I would like to add that the above is only possible if you "plan" the work. If you have expectations of how a certain task should be accomplished then you should be able to define the task on a detailed enough level so that you "can" delegate it and that the team member working on it actually has the ability to complete the task according to your expectations.

There is nothing worse for a team member to be given some vague idea of what should be done to then afterwards having a big discussion on the expectations, i.e. how to be a mind reader.

</comment></comment><comment><USER32> Regarding people skills, I always recommend Peopleware[1].

[1] [http://www.amazon.com/Peopleware-Productive-Projects- Teams-3...](http://www.amazon.com/Peopleware-Productive-Projects- Teams-3rd/dp/0321934113/)

</comment><comment><USER33> In no particular order:

1\. _Listen before you speak._ The people you manage are prone to giving your opinion more weight than it deserves.

2\. _Give your subordinates problems, not solutions._ People like to own a task, not to be told what to do; treating them like adults and professionals empowers them and brings out their potential. Besides, if one person only ever makes all the decisions, no decision can be better than that one person's knowledge. If you're afraid of delegation, institute a tight review loop to ensure that people don't go off-track.

3\. _You 're a facilitator, not a doer._ People will come to you with their problems, and you _must_ be available at all times to help them through it. As someone else has pointed out, your productivity is secondary to that of the team. It's your job, among other things, to ensure that your team has a good working environment, including good tools, practices, and access to uninterrupted "flow" time.

4\. _Be aware of politics._ The moment you manage a team, politics become a part of your daily job. This is not a bad thing—"politics" just means managing interpersonal relations; it becomes a bad thing when you ignore it.

5\. _Never be in a position to take._ Success belongs to your teammates; failure is all yours.

6\. _Face problems head-on._ People don't like confrontation, and let problems fester until it's too late to fix them. Instead, provide frequent one-on-one time with all your teammates, exhort them to confide in you, and show them that you're trustworthy. Also see #1.

7\. _Offer clarity._ Explain what you expect others to do in a _measurable_ way to make it possible for both you and your team to understand how well everyone is doing. You can use a method like OKR[0] to track your goals internally.

[0] [https://en.wikipedia.org/wiki/OKR](https://en.wikipedia.org/wiki/OKR)

</comment><comment><USER34> One thing that I've not seen mentioned is that you don't have to feel like you're the one that has to answer all the questions, just because you're the lead. Deferring questions to those you feel may have more specific knowledge shows that you know where your weaker areas are and where the strengths of your team are.

This also goes for asking your team questions, don't be afraid to ask them things you feel unsure on rather than try and power through.

</comment><comment><USER35> Book: Becoming a Technical Leader by Jerry Weinberg is a good read and one that I re-read often - [https://leanpub.com/becomingatechnicalleader](https://leanpub.com/becomingatechnicalleader)

</comment><comment><USER36> In addition to everything already said, I reemphasize:

\- allow your team to focus

\- provide just enough structure (and no more)

\- help shorten feedback loops

\- try to remove hurdles to acquiring information

Deep focus unleashes creativity, passion, and great work. I know that's when I'm the happiest.

</comment><comment><USER37> Management is a completely separate set of skills from engineering, and a set you have to force yourself to learn. The best book I've read on the subject is Andy Grove's High Output Management [1] -- it talks about how to choose tasks with the highest leverage, how to run meetings and one-on-ones, how to make managerial decisions, and how to motivate your team.

[1] Cliffnotes at [http://charles.io/high-output- management](http://charles.io/high-output-management)

</comment><comment><USER38> all of these lists sound nice and all, but think back to the people that you really respect that have taught and influenced you to become who you are today.

what was the most important part? for me it was the person who was many degrees smarter than the rest of the team and pushed everyone to be their best. In my case he was not the most diplomatic or encouraging, hell he yelled at me a few times (and trust me, i don't appreciate being yelled at even by my parents). but anyone who was interested in software engineering was in awe of his skill. He devoured tech books and prototyped things on the train to work so that he always had good ideas and answers. I was sold right from the interview where I could tell he just knew his stuff inside and out. My point is that having the necessary knowledge to actually teach people is so much more important than all those other things. For most of us that means a lot of hard work in the trenches during free time. New technology? there goes Saturday and Sunday. It's the only way to have all the answers to the ones above you, and the ones you're leading.

Additionally try to get your team the best development/infrastructure tools money can buy and the best learning resources (such as pluralsight, egghead.io, all-you-can-read online books subscription)

</comment><comment><USER39> I've been a team lead for less than a year but it feels somewhat natural for me since I've handled leadership roles informally on projects in the past. The hardest thing is having to delegate when a fire's going on that you know how to fix but you have to stop trying to uh... "do work"

If you embrace that you're expected to be a force multiplier for the team, you have the right mentality. But being sensitive to what role you need to play is critical. Sometimes you need to be a tie-breaker on a heated argument on a framework decision (lead by wisdom / deference to your respected authority), perhaps people are in despair and they just need someone that puts everyone at ease that something's being done right and you should just step in and write a reference implementation (lead by example).

One thing I would add is that you should find out if there's a program / product manager present and ask to interview with that person if you haven't. If there's no such role, you will have to pull triple duty as a product / program manager potentially by making a lot of strategic decisions probably. At that level, you might as well be considered a CTO though rather than a technical middle manager basically.

</comment><comment><USER40> A colleague of mine wrote a useful post on this: [https://medium.com/swlh/good-tech-lead-bad-tech- lead-948b2b8...](https://medium.com/swlh/good-tech-lead-bad-tech- lead-948b2b806d86)

</comment><comment><USER41> OP, I'm sort of curious why they're hiring a tech lead from the outside. Why hasn't someone taken that position from within the organization? Someone who's worked on the project, who understands it, who has the moral and political authority to lead? I worry that your task will be really, really tough. If you can, in the interview, try and understand the situation over there. Why do they need an outside lead?

<comment><USER42> Hmm.. I didn't necessarily read it as they were hiring from outside necessarily.. I'm sure it's not uncommon to have interviews internally even if all of the potential candidates are already employees.

<comment><USER43> > I'm sure it's not uncommon to have interviews internally

In fact depending on location it may be legally required - I'm fairly sure this is the case in the UK (in addition to having to advertise the opening externally too, even if there's absolutely no intention of hiring anyone external) - please someone correct me if this is wrong.

Probably the sort of thing early-stage startups can get away with not doing because they're very under the radar, but it's certainly happened at mid-sized companies I've worked at.

</comment></comment></comment><comment><USER44> Being a team lead means you must manage in three directions:

a) manage the expectations of your boss and shield your team from distractions and firefights,

b) manage collaboration and dependencies with other other teams, and

c) manage the day to day work of your team.

</comment><comment><USER45> I've been a Tech Lead for a year now. I'm still learning but some of the things I've done which I think will help are:

1\. Start by setting up the development environment and getting the software you'll be working on to run locally. Then, fix a couple of easy to medium level bug fixes as soon as possible. This is the fastest way to learn what your team is talking about.

1.5 If you don't understand something that's being said at a meeting ask, but don't hijack the meeting, make a note and talk to someone who can explain in more detail.

2\. Think at a high-level -- what is the product supposed to be doing, abstract away -- some engineers will talk in code -- which you may not understand early on but interpret what they're saying at a high-level.

4\. Be available and approachable to everyone on the team.

5\. Understand the impact of a bug fix or a feature -- how much QA effort does it require, what is the operational impact of the work, does it break backward compatibility etc.

6\. Participate in product meetings and consider designing any new features as homework so you can better discuss it with the engineering team you're leading.

Good luck!

 _Edit_

Some DO NOTs:

1\. Do not complain how bad the code base is. No one likes someone new walking in and saying that at once.

2\. That said, understand what technical debt there is and address it incrementally. Don't say "we should re-write XYZ."

3\. Do not suggest alternate platforms and frameworks unless is absolutely makes sense -- this is especially true if the team is big and no one knows this new framework besides you. You need your existing team to contribute to and maintain projects.

</comment><comment><USER46> What worked for me was to learn to listen to people, to let them explain the problem and sometimes find an answer as they were talking. What helped was to do lots of peer reviews of both code and documentation so the the young ones could learn from the old ones and the old ones could get new ideas or more up to date ways of doing things from the young ones. I came to realise that programming is flow based while leading a team is interrupt driven so I had to learn how to do context switching quickly and to block out areas of time when I could do my own programming. I had to learn to help people do their work and restrain myself from rushing in to do the work myself. And I had to learn that my team members were people who had lives outside work that affected the work they did.

For example, I had a team member who was a good programmer but had trouble coming to work on time. He was getting married so I bought him a clock radio as a wedding gift. That fixed the problem.

<comment><USER47> Great to hear others have gone through a similar process to the one I am taking now.

> block out areas of time when I could do my own programming

My biggest challenge is that this time for me is evenings and Sundays afternoons which eats into the work/life thing.

<comment><USER48> Maybe take off fridays, and make Sunday a formal work day.

</comment></comment></comment><comment><USER49> Some gems from when I asked something similar 4 years ago...

[https://news.ycombinator.com/item?id=3407643](https://news.ycombinator.com/item?id=3407643)

<comment><USER22> Nice link. How have the last four years gone for you?

</comment></comment><comment><USER50> There is some great advice in this thread. One thing that I've learned is that different organizations have very different cultures and ways of viewing technology (and thus technology leadership).

Some are more deadline oriented, some are more bug/problem oriented, and some are more product oriented, and others care a lot about the price per head of engineers and would prefer to outsource everything to the third world if they could ever manage it. A small number of companies care about open source contribution, attracting top talent, and innovating.

So whoever is hiring you probably has a very clear idea of what they want from the tech lead, so considering that the goals can be very different, you might want to ask this question. In my opinion, it won't seem like a naive question to ask because there are so many facets to people and technology leadership.

</comment><comment><USER51> I just took a technical lead role with a bay area SAAS company. It's been a difficult adjustment having worked on contract where all I did was write code. Now, I sit in a lot of meetings, do code merges, interview/hire developers and worry about blockers on two Jira boards. Here are a few things you might want to try;

If their branching strategy is screwed up, help them fix it. You are going in to a .net shop and there is a good chance they have TFS. There is the ALM Rangers branching guidelines you can refer to.

Hold a brown bag and show the team how to write unit tests. Many of the junior developers on the team probably do not understand how to write tests.

Hold a team code reviews.

Initiate common architectural components like a logging or instrumentation framework.

Take on tiny bites of technical debt.

Push to get your team re-sharper licenses.

</comment><comment><USER52> I heard about this model from Michael Church, which I like. The idea is that there are three forces, you need to balance as a manager.

1\. Your team. This is obvious. Acknowledge they are humans. You have to worry about them. Try to keep them happy and safe.

2\. The Business. This is the cold-hearted inhumane entity which only considers the free market. You need to satisfy that beast, because otherwise everybody loses their jobs. It only wants to squeeze the maximum productivity out of its employees. Often its goal are in direct conflict to your teams goals.

3\. The Organization. These are all the other people in the company. Your boss, collegues in other teams, etc. They have their own needs and agendas, usually different to The Business. Do not forget to consider these.

</comment><comment><USER53> My summary, after many years thinking about it, is: Build technical leadership in depth.

What ever you do, what ever the problem. It's a key-person problem unless your team can do it.

If you have to tell your team what to do. You are failing, and you need to do something about it.

The leader sets the vision, makes as start, demonstrates good and keeps people on track. The coach makes people the great person they want to be. A leader can use simple coach techniques to grow an resilient team who can work to build something great.

I've noted down some of my learnings: [http://www.engineeringandcareering.co.uk/p/leading-and- guidi...](http://www.engineeringandcareering.co.uk/p/leading-and-guiding- groups.html)

</comment><comment><USER54> A couple articles I've seen previously on HN on the subject:

Things I was unprepared for as a lead developer -- [http://dev- human.io/~pascaldevink/things-i-was-unprepared-fo...](http://dev- human.io/~pascaldevink/things-i-was-unprepared-for)

Becoming a Tech Lead – Interview with Pat Kua -- [http://blog.fogcreek.com/becoming-a-tech-lead-interview- with...](http://blog.fogcreek.com/becoming-a-tech-lead-interview-with-pat- kua/)

</comment><comment><USER53> I guess I should really answer your question though :) I collected some interesting blog posts that I loved and stuck them here

[http://www.engineeringandcareering.co.uk/2013/07/technical-l...](http://www.engineeringandcareering.co.uk/2013/07/technical- lead-articles-and-blogs.html)

Talking with Tech Leads might interest you also: [https://leanpub.com/talking- with-tech-leads](https://leanpub.com/talking-with-tech-leads)

</comment><comment><USER55> 1) Solicit ideas from everyone. Admit when you don't know the best way. Attempt to achieve consensus. But be steadfast in the face of majority opposition when you're sure you do know better.

2) Insist on always doing the right thing. Never compromise your standards or your ethics [0]. You set the example for everyone else.

3) Treat your customer like an honored guest in your home. Bend over backwards to understand them. But never let them anywhere near your developers. It's not good for anyone, _especially_ the customer.

4) Always take the heat for your team (which is easier if you're the single point of contact for the customer). Always spread credit around.

5) Don't get personally involved with your team [1]. You might have to fire one of them one day. And your praise will mean more. You can socialize with the whole team on occasion, but don't do anything that could ever allow the appearance of favoritism to develop.

6) Trust people to do their work. Give them a chance to succeed... or fail. But the few that repeatedly and consistently fail to live up to expectations or even improve, get rid of.

[0] If anyone ever tells you "we might as well do this unethical thing, because the customer will just get someone else to do it," your reply should be, "well then, it doesn't have to be me" and walk away. I have done it twice now and have regretted neither time.

[1] I would like to think this goes without saying, but NEVER EVER EVER make sexual or romantic advances towards anyone under you. It is extremely unethical. If there is any chance of something happening, wait until you're no longer on the same team. Best to wait for them to make the first move, too, if you're still at a higher authority level after the team change.

</comment><comment><USER56> I really enjoyed "Notes to a Software Team Leader: Growing Self Organizing Teams."

The second half of the book is advice from various tech leads.

<comment><USER57> I can't recommend this book highly enough. This is the best book on tech leadership I've come across and I've read a lot of them.

It underscores the importance of _NOT_ trying to solve problems for your team. Instead, help your team learn to solve problems on their own--so you don't become a bottleneck to getting things done.

</comment></comment><comment><USER58> Candour, honesty and therapy. And enforce ridiculously high standards.

Most of us are not as good as we say/imply we are. All of us are terrified that someone will find out, and terrified that we will slip. So there is often a refusal to say "I don't know" or a refusal to accept that we might need to slow down and think about the work we are doing

Your best bet is to make a team that is willing to try something that will make them look like they don't know what they are doing, send off signals to "management" that are opposite of what all the other teams are sending. (This is the other point about a tech lead - you will be compared to the other tech leads - if they are hiding their faults, you will look bad by comparison as will your team - how you persuade management this is not the case is hard.

My best suggestion for that is ridiculously high standards - perfect test coverage, documentation, linting, enforced peer review and more. For every commit. Enforced by scripts not by you.

</comment><comment><USER59> Good read: [http://dev-human.io/~pascaldevink/things-i-was-unprepared- fo...](http://dev-human.io/~pascaldevink/things-i-was-unprepared-for)

Discussion: [https://news.ycombinator.com/item?id=10223472](https://news.ycombinator.com/item?id=10223472)

</comment><comment><USER60> I would suggest to always put yourself in the shoes of the developers when you make decisions as a leader. Think about what you would have thought as a dev.

Also try always to explain why you make the decisions you make.

I am a dev and I hate when decisions are made without telling/explaining team members. I also appreciate a lot when I receive feedback, good or bad.

</comment><comment><USER61> [http://5whys.com](http://5whys.com) \- I'd recommend a lot of the advice there (I'm the owner of that blog so I'm a bit biased).

[http://teamleaderbook.com](http://teamleaderbook.com) is a book that I wrote for software team leaders

<comment><AUTHOR> Well, that's too amazing to be true - as part of my preparation I started reading "The Art of Unit Testing" just a couple days ago (not that I did not write tests before, but got a suggestion that the book will help me better understand dependency injection, inversion of control etc.)

<comment><USER61> heh! It's a small world!

</comment></comment></comment><comment><USER62> Wow, I can't say I'm surprised at the quality of the answers. I'll add a couple of my own:

.) be mindful that different members of the team are on different trajectories skill set wise. (beginner Exs -> juniors -> mids -> seniors -> etc)

I like to pair members with technology whose stability is inversely proportional to their experience.

More experienced engineers design tighter interfaces in the face of increased variability in final spec.

Whereas technology that is older will usually have a good breadth of info either in house or available on Stack Overflow which means the problems (and communally derived solutions to them) are accessible.

This I've found results in having to clean up less code overall, which helps build team momentum.

Which is my next point.

.) Team Momentum

You're leading a team, which can be assessed as a set of quantities at any given point in time (viz. velocity in Pivotal Tracker for instance).

The team however is a dynamic interplay of business expectations (from the principal, boss, client) technical debt (recurring known issues), and the team strength (which waxes and wanes based on moral, environment, etc).

Always look for ways to make the lives of the engineers around you easier.

-) build tooling

yeoman generators build tools etc.

enriching internal tooling makes each engineer more effective, which means it has a compound effect.

      You can cover a lot of ground just focusing on addressing pain points in your team.

]) One last point actually, you're a leader so remember that means you're expected to have finer grain control over your ego, it helps if you take an objective view towards the technology that comprises your stack rather than a predominantly fanatical view.

Congratulations by the way! Regards,

Dante Elrik

</comment><comment><USER63> [http://katemats.com/](http://katemats.com/)

</comment><comment><USER64> You can get a summary of this discussion here: [http://sevcode.tumblr.com/post/131264031520/the-30-laws- of-s...](http://sevcode.tumblr.com/post/131264031520/the-30-laws-of-software- management)

</comment><comment><USER18> This seems prescient as I will be starting a new job as a tech lead in a week, and I actually considered making the same Ask HN post! Same tech stack, no less, although it's for 2-3 medium-sized projects, not a single large, complex one.

Best of luck on your interview.

</comment><comment><USER65> Lessons I learned as Tech Lead:

[http://scottndecker.com/blog/2015/04/04/Tech-Lead-Lessons- Le...](http://scottndecker.com/blog/2015/04/04/Tech-Lead-Lessons-Learned/)

</comment><comment><USER66> At the core of it - you're going to be leading engineers. A lot of how this leading happens depending on the organizational makeup of the firm you're going to. (This is super super important!!!).

So figure out the organizational culture before you join. Understanding this helps you understand the confines within which you will operate (for the first couple of months, atleast). If you're replacing someone, understand how they worked, what gaps were there in that person's performance and how you could cover those. If you're the first tech lead, then figure out what problems they're having that necessitated the creation of the tech lead position.

</comment><comment><USER67> I've found this a really good discussion of how tech leads' responsibilities differ from front-line developers:

[http://madeofmetaphors.com/shapes](http://madeofmetaphors.com/shapes)

</comment><comment><USER68> This fellow writes some good articles on the subject and will send them via a mailing list once a week:

[http://marcusblankenship.com/list/](http://marcusblankenship.com/list/)

</comment><comment><USER69> Read this set of articles: "Things I wish I was told when I became a manager" [http://fractio.nl/management/](http://fractio.nl/management/)

</comment><comment><USER70> [http://www.engineeringandcareering.co.uk/p/the-well- rounded-...](http://www.engineeringandcareering.co.uk/p/the-well-rounded- technical-lead.html?m=1)

</comment><comment><USER71> After you get the job, here's something my old team learned through experience (failure): modular is good, but in practice, abstracting things to the theoretical max results is software that none of the developers understand, is impossible to maintain, and probably doesn't perform any better than if you didn't "optimize" near as much.

(Source: I was a programmer, then a tech lead, then moved into managing about 100 of them.)

Another tip: it's your job to help the programmers make you look good. You do that by making them look good. It _should_ be a virtuous cycle.

</comment><comment><USER72> There's plenty of great advice already in the comments, but mine is quite simple, and quite relevatory when I made the transition to Lead:

Measure your success by your team's productivity and not your own.

</comment><comment><USER73> \- Be flexible

\- Prioritize everything

\- Simplify code, processes, and infrastructure at every step

\- Build a well-rounded, emotionally stable team

\- Loosely follow scrum & agile

\- Be realistic

\- Be honest, even when it is inconvenient

\- At the tech lead level, the most important skill is your own psychology. Hone your personality, establish work-life balance, and take some courses in positive psych

\- Have an opinion

\- Learn when to talk, when not to talk, when to put it in writing, and when not to put it in writing

\- Adopt a "good enough, and let's move on" design approach

\- Build strong relationships with non-technical management

</comment><comment><USER74> You need to read this...

[http://www.altisinc.com/resources/rules/](http://www.altisinc.com/resources/rules/)

</comment><comment><USER75> I would stress this the most: support your team. Give your team the technical and emotional support they need to do their jobs well and _have fun doing it_.

Some things I've noticed that had the largest impact on employee engagement:

-

1\. Poorly defined development processes heavily impacts morale. Define your code standards, your process for picking a library to use, how you handle versioning of code (and which methodologies), how your team should escalate problems, and expectations of individual team members. Document this in a place where anyone on the team can view it.

2\. All projects require documentation on how to setup a build. If that doesn't exist, developers ramped up on the project will loathe the project from the start (and in some cases, the team lead). From scratch, setup a project before handing it off. Document everything you had to do.

3\. Onboarding of new team members: make yourself or someone you appoint available at all times for the first week or so. Document and fix anything the new team member needed help with. Onboarding is hard, this will be an ongoing process.

4\. Setup one-on-one meetings. Once every couple of weeks seems ideal in my experience. Don't have an agenda, but have a few questions you resort to for filling in quiet spots for the more introverted types. Don't be afraid to ask hard questions (did you have a problem with Robert in accounting last week? are you happy with your salary? what would make you happier?). This meeting is key to employee retention and team happiness.

5\. Allow for an open discussion on all major decisions. Have a tool in place where anyone can raise problems. If someone can post anonymously to start a topic, that's ideal. That is where some of the best business growth will take place.

6\. Read a book on mentorship. Mentor your team. If someone surpasses your skillset on the team, you've succeeded. I've not read all of Maxwell's books, but he has some really great insight in the couple I've read: [http://www.amazon.com/John-C.-Maxwell/e/B001H6NROC/](http://www.amazon.com/John-C.-Maxwell/e/B001H6NROC/)

7\. Become known as an advocate/mediator for those on your team and the higher-ups. Fight for your team when you need to, and fight for upper management decisions when you need to. Finding a balance is important, but never lose trust of those you lead.

-

In many cases, becoming a technical lead also means you are expected to learn the business side of things. It wouldn't hurt to read business-oriented books. Anything by Jim Collins is great (Good to Great is a must-read): [http://www.amazon.com/Jim-Collins/e/B001H6GSHK](http://www.amazon.com/Jim- Collins/e/B001H6GSHK)

Best of luck, and congratulations on your learning opportunity!

<comment><USER76> \+ for mentioning on-boarding and implications, another + for mentioning open discussions on things that matter

</comment></comment><comment><USER47> I think it can be summed up as "code less".

I want to stress that this is much more easily said than done.

\- A lot of programmers gain immense satisfaction from writing nice code, and getting into "flow". There will be less of this, and you have to rewire your reward system and vicariously experience this through your team. If you already get more satisfaction from shipping and having users use your product/module/apis rather than how elegant your code or apis are, then you are heading in the right direction.

An earlier comment on this page sums up the goal:

> Your satisfaction changes from being happy that you've polished some nice > bit of code to being happy that you've shipped a product and successfully > run a group, and gained the admiration of the people on your team and in > your company. Competence is it's own reward.

\- You must prepare yourself to watch others implement things you would love to do yourself, in a less-optimal, and less-clean way than you might have. Its harder if the codebase is your baby that you wrote from scatch. Instead of coming out of a project with new skills, new familiarity with modules, code that you could open-source, satisfaction from having written nice modular, maintainable and testable code, you will only have the satisfaction of the hitting a deadline.

\- Coding less allows more time for you to ask your team what they need, think about what they need but don't realize, and get that for them.

\- Giving feedback is an art. You want to keep a positive, upbeat repore with your colleagues. If you empathize too much about how the developer will feel when you deliver criticism you will end up doing it less and not being as honest. Finding the right words will make it easier for yourself to deliver, and will create less tension.

\- Hiring people like yourself who write code similar to you will make life much easier - but often you have to money-ball your team, and make do with what you have.

\- Creating an atmosphere where employees can all talk about problems, and personal mistakes, without feeling judged by their peers is important. Encourage everyone to acknowledge their failings, and identify improvements. "What did everyone learn this week/sprint? What could you do better?". As soon as employee holds back, everyone will start because they will fear they are underperforming. If someone is falling behind, others in the team should be thinking how they can assist their colleague, rather than looking at it as an opportunity to stand out. Standups are great for this. Make sure its not only one person asking for help at the standup.

</comment><comment><USER77> 1) Learn as much about the people on your team as you can. That can be sometimes hard while at work, so I end up going out to lunch with them or occasionally grab a beer afterwards.

2) While at lunch or after work, my team and I end up talking about random stuff, but it pays off when you can sense if someone is having a bad day/week or is stuck on a particular issue. Also helps to build mutual trust with your team and keeps the communication lines more open.

3) It's hard to sometimes tell how well you're doing as a technical lead, but one way I do it is by how often people come to me for help to things that can't easily be Googled. If developers are seeking out your help, they trust you and consider you reliable source of help.

4) If it comes down to doing more work or helping your team. Always pick your team. Helping them will likely be more productive overall than any amount of additional work you take on yourself.

5) Every developer is different. Recognize that when communicating with them and approach each differently. A true tech lead isn't a managing position, it's a mentoring/leadership role while still being a developer.

6) Be concise. Your team needs help, but they have work to do. Save the long explanations for later. That doesn't mean you should avoid the "why" in your responses, just don't make your answers a monologue.

7) If asked by a team member why you think a particular approach or solution is correct, give them an explanation. I always feel if I can't explain a particular subject, then I don't really know it that well and may be incorrect.

8) You don't always have to be correct. Admitting you aren't when you can't explain something reflects better than all other responses you could give your team.

9) Making yourself available to your team for assistance is also a must as already mentioned. Everyone communicates differently, so adjust to your team as much as possible.

10) Don't deter someone outright from pursuing a potential solution, even if you're pretty certain it won't work. Instead saying no, apply some rubber duck debugging[1] and talk them through their idea aloud. If all goes well, they'll either realize it's not feasible and learn the value of communication or they'll convince you that it will likely work. If they win me over, I'll try to help them devise a way to small way to test their idea further.

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

</comment><comment><USER78> A great technical lead is a great therapist.

They're kind, supportive and know how to focus your energy to help get a really difficult task done. They don't dictate, they don't prescribe, they listen.

Your job as a tech lead is to listen and help figure out a way to make testing, compiling, deployment, support, and escalation easier.

</comment><comment><USER79> Many times a tech lead isn't about being the smartest or most knowledgable person in the room - it's about getting your team, your boss, other departments on board with a plan and executing. In some environments it may be that you have to be the sharpest depending on the team you're given, but often times it's best to be the most judicious and compassionate. Think of it more like being a mini-manager - perhaps 30% management (where you're like an extension of your supervisor) and 70% software. Also be prepared to bring your boss into issues you may have with external teams/organizations, but try to shield your team itself from that activity. Be prepared to handle considerably more email, process work, signing of documents, etc.

I'm going to share a personal story - it might not have much directly actionable advice, but it may give you some thought on how to approach this strategically.

I spent about 15 years as well on windows software for enterprise health care systems (starting back in VS6 C++ days back in the late 90s) before jumping ship to do Rails development a few years ago.

Right around the 10 year mark in my career I was a run of the mill sr. dev... the only 'lead' experience was on a couple projects, rarely with more than another dev and most of the time solo. I just never really had much confidence in my skill set as a whole, esp. when it came to telling other devs what to do. In 2009 as a 33 year old I felt pretty deflated and was considering a career change. One thing I caught wind of was this book called "The Passionate Programmer" by Chad Fowler (not related to Martin). It was ~200 pages, and it was separated out into 50 or so little chapters of tidbits of mostly, well, soft skills, but also general career advice. I absolutely loved it and finished it in an evening.

In short order a whole bunch of things about my working style changed, not only my demeanor working with other engineers, but key key people in other departments in the projects I worked on(ie. QA, System Engineer, Documentation, Product, Project Management). Ultimately I realized at that particular organization the biggest problem was that departments were silo'ed a bit too much, and as a result schedules slipped because coordinating resources was always a challenge.

Six months after reading the book I was given a lead role on a medium sized project at that company (had 6 engineers on the team and about 20 people working on it for 9 months, ~$15M per annum, 300k LOC over the prior 10 years). One of the engineers who reported to me during on that project was one of the 2 Fellow Engineers at the company (3 titles above mine!). It went well, and my next review had a recommendation from my supervisor to go into management. I politely declined and a few months later was promoted to a principal dev.

One of the reasons why I believe this worked so well was 1) I did underestimate my skills as a whole - I was not the best, but I was certainly good enough that my suggestions held weight and I felt ok with admitting to things I didn't know and delegating 2) I had, as you say, seen other people in this position and already knew what success and failure looked like. I wasn't just given a position as a lead, I had assumed it to some degree on another project I was on at the time (not entirely and not to usurp the authority of the actual lead, but I just became helpful on things that needed to be done but were getting brushed aside, esp. things that were important to other departments). And as such, people started to pay attention to what I was saying.

It sounds like you think it's slated toward being an architect. It can be, but many times it really isn't - you may want to delegate that overall to the stronger members of your team and help them work through the process - be the person who asks questions and helps poke holes. Give the most challenging work to your brightest people. Isolate the more 'dangerous' members from mission critical stuff, and if they have the passion and smarts but they're just a bit misguided give them a nudge of encouragement in the right direction and challenge them accordingly. Pay attention to your devs' key strengths and delegate accordingly, but also remember to provide a degree of work that is challenging and exciting.

So that's my advice - check out that book. It's a quick read. It is about 6 years old now but the advice is mostly generic. Try to put some of it to effect in your current job... assume the role where you can. Even if it's just a week or so, I think the best practice is actually trying it out in real life.

<comment><AUTHOR> Thanks a lot. I'm sure I read the book a few years ago ... will have closer look to make sure I'm not confusing it with "The Pragmatic Programmer".

<comment><USER79> Absolutely. Best of luck!

</comment></comment></comment><comment><USER80> i enjoyed reading the book Team Geek [http://www.amazon.com/Team-Geek- Software-Developers-Working/...](http://www.amazon.com/Team-Geek-Software- Developers-Working/dp/1449302440)

<comment><USER81> I liked Michael Lopp's (also known as Rands, from Rands in Repose) book, Managing Humans, when I first became a team lead 18 months ago.

[http://www.amazon.com/Managing-Humans-Humorous-Software- Engi...](http://www.amazon.com/Managing-Humans-Humorous-Software- Engineering/dp/1430243147/ref=sr_1_1?s=books&ie=UTF8&qid=1444939385&sr=1-1&keywords=michael+lopp)

</comment></comment><comment><USER82> Most of all, make your contribution visible to your leader, or to KPI, or to anything evaluating your contribution. If no one knows your great works, It worth nothing to your career.

First, know how they evaluate your works.

</comment><comment><USER83> Checkout [https://leanpub.com/becomingatechnicalleader](https://leanpub.com/becomingatechnicalleader)

</comment><comment><USER84> also worth reading: [http://www.amazon.com/Driving-Technical-Change-Terrence- Ryan...](http://www.amazon.com/Driving-Technical-Change-Terrence- Ryan/dp/1934356603)

</comment><comment><USER85> You lead the way and when you have half of them with you, the rest will follow.

</comment><comment><USER86> Do you have a few kittens? Managing developers is like herding cats.

The truth is you don't really have real control.

</comment><comment><USER87> Great question! I just wrote an article on this very topic here...

[https://www.linkedin.com/pulse/real-work-management- marcus-b...](https://www.linkedin.com/pulse/real-work-management-marcus- blankenship?trk=pulse_spock-articles)

If you're looking for books, I recommend Johanna Rothman's "Behind Closed Doors" as a great book about leading software teams.

Good luck!

</comment><comment><USER88> Learn to listen. To your team members. To your peers. To your boss(es). To people in other departments. Not just to their words, but their body language, their activities, the way they carry themselves in meetings.

I am constantly learning from the people around me how I can be a better manager. If I see something that catches my attention about the way someone handles something, I aim to bring that into my own toolkit.

</comment><comment><USER89> Just try not to get fired.

<comment><USER22> Come on guys, I know we don't generally appreciate humor here, but this is pretty fucking funny.</comment></comment>


High-performance garbage collection for C++ · V8 - <AUTHOR> https://v8.dev/blog/high-performance-cpp-gc <comment><USER2> I think this might be of interest:

[https://chromium.googlesource.com/chromium/src/+/master/thir...](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/platform/heap/BlinkGCDesign.md)

It contains answers to how things are done internally, the threading model, etc.</comment>


Blocking web ads is 'as bad as Napster' - <AUTHOR> http://www.theguardian.com/technology/2014/sep/09/blocking-adverts-napster-for-the-publishing-industry

<comment><USER2> Quote from the article: "Research shows that very few people find advertisements in more established media annoying,"

I wonder where this "research" was conducted. I find any and all advertising annoying, no matter where it is located.

The difference between "more established media" (which I interpret the author to mean print/television) and the web is that the user has little control over being force-fed the advertising.

What they are really upset about is loosing the control to "force feed" users ads against their will.

<comment><USER3> Personally, I find tv and radio ads extremely annoying. But everyone who's experienced it finds my habit of muting the tv during ad breaks to be very strange.

So I can easily believe that I am in a small minority on this.

On the other hand, I generally don't object to adverts in newspapers and magazines.

</comment></comment><comment><USER4> When advertising companies weren't tracking my every move I had no problem with their ads. Since they seem to have decided I need to be profiled rather than to just use the contents of the page to determine what ad to display I have decided to stop honouring my end of the unwritten agreement and I feel absolutely no sense of guilt for that.

If an advertisement company pledges to stop any and all tracking I'll happily white-list them, even though I absolutely loathe any form of advertising I think that a company that would make such a pledge and would stand by it would deserve my support.

<comment><USER5> I feel the same about profiling, but it's hard to deny that publishers are in a difficult position. Say a publisher wants to stop tracking us. How would they go about it and how would enough people learn about it?

For publishers, not tracking users without destroying their revenue stream seems about as intractable as it is for users to block more selectively

</comment></comment><comment><USER6> I hope they aren't trying to make adblocking illegal, because that's the vibe I felt when reading the article.

They should make it trickier to block them, if anything.

</comment><comment><USER7> See [http://en.wikipedia.org/wiki/Social_contract](http://en.wikipedia.org/wiki/Social_contract)

<comment><USER8> The problem with this is that the ads are absolute: you get what they choose to throw at you. There's no sense that such-and-such an ad is apppropriate for such-and-such a site or user or time of day, just a firehose of attention- grabbing demands.

..and that's before we get onto the properly evil stuff, the ads that pretend to be UI elements or do Bad Things via scripting.

I can't control whether my ads are just ads, and not some heinous keylogger disguised as a porno or a cavalcade of exploding ponies. This is the social contract being broken by the advertiser. They can pout all they like, I'm still blocking.

<comment><USER7> What we need is a Nielsen ratings report for ad-blocking which reports statistics on sites being blocked, because either the publisher or advertisers have broken their social contract with readers.

For example, some readers may have strong opinions about publishers that embed Taboola "related links" without disclosing if they are clickbait advertisements.

</comment></comment></comment><comment><USER9> Apparently "adblocking" is now a word.</comment>


[video] Russ Olsen – To the Moon - <AUTHOR> https://www.youtube.com/watch?v=4Sso4HtvJsw

<comment><AUTHOR> This is a talk at the Clojure Conj about some of the interesting stories surrounding the lunar landing and how it relates to large-scale software projects.</comment>


Show HN: Friendex - a Pokédex of your friends. - <AUTHOR>

Hey HN,
My first app, Friendex, is FREE and available in the App Store.
It is my very first personal project and it was a lot of fun to build.
Feedback on how to improve it would be great!
I am also a freelancer, and am looking for new projects. I would love to talk about any project you're working on and/or need help with. You can find my contact info in my profile.
Thanks! <comment><USER2> You should tell us about it and why we need it. I don't think many people will try it until you do.

</comment><comment><USER3> It looks nice, but you're app could easily get kicked for copyright infringement.

<comment><AUTHOR> Thanks! Nintendo seems to be pretty lenient on app developers. There are many Nintendo-themed apps that are making a lot of money in the App Store, and I can't remember one that's been pulled.

<comment><USER4> They went after Pokedex apps a while back, around when B&W came out.

</comment></comment></comment><comment><AUTHOR> Link: [https://itunes.apple.com/us/app/friendex!/id664874851?ls=1&m...](https://itunes.apple.com/us/app/friendex!/id664874851?ls=1&mt=8)</comment>


Ask HN: Gadget Question (A device that has email, google reader, twitter) - <AUTHOR>

Is there any gadget out there that has the following capabilities and is under $20/mo. for a 3G data plan?
- 3G Connection
 - Google Reader
 - <USER2>
 - eMail
Peek comes close, but no cigar. iPhone has 'em all, but with a $100+/mo. pricetag; same with most noteworthy pda's.  No purchase-worthy available tablets, right now.
Thanks <comment><USER3> Forget about the device; I don't think there is any 3G data plan for $20/month.

</comment><comment><USER4> iPhone 3Gs is around $70/mo, not $100.</comment>


Haml & Sass 3 Beta Release - <AUTHOR> http://nex-3.com/posts/94-haml-sass-3-beta-released

<comment><USER2> I actually love sass the way it is currently, what benefits does this new syntax have for previous users of sass? I see how this new syntax could maybe help new users since it is more aligned with regular css. What I am most interested in is support for sass to minimize duplicated sass/css. Sass is great because it allows for semantic css styling where you include mixins of common css, but that increases the size of the css. What would be great if sass allows us to write semantically, but when you deploy, it should minimize the css.

<comment><AUTHOR> Sass users will enjoy the following features:

      * No more = needed to use SassScript
      * $ instead of ! for variables
      * Support for CSS identifiers. E.g. solid instead of "solid"
      * Dashes can be used in place of underscores in variable names and sass functions.

There are a number of features planned for Sass 3.2 and beyond that address your other concerns, but Sass needed better infrastructure to do those. We have that now so we can go full steam ahead on new features. Expect the following in future releases:

      * Defining custom functions in Sass
      * Keyword arguments to mixins and maybe functions.
      * Support for a new directive called @extend
        that implements selector inheritance.
      * Optimizing compiler
      * Support for new core datatypes like List and Null

<comment><AUTHOR> Downvoted; really? What part of this reply was uninformative or offensive or off topic? FWIW, I'm one of the developers of Sass: <http://nex-3.com/posts/78-chris-eppstein-joins-sass-team>

</comment></comment></comment><comment><USER3> Three months ago I wrote a little piece of rant about Less vs. Sass here (<https://riobard.com/blog/2009-12-18-less-vs-sass/>). The day after I posted it, Nathan Weizenbaum (author of Sass) emailed me saying those tiny problems will be fixed. Now they delivered it. Time to give it another try!

</comment><comment><USER4> Interesting changes. I like less, but probably time to give Sass a second look.</comment>


Uniform and Normal Random Number Generator Shootout - <AUTHOR> http://www.victusspiritus.com/2011/06/19/uniform-and-normal-random-number-generator-shootout/ <comment><USER2> I'm sorry, the quality tests are garbage. Anyone who's done even a cursory amount of research into PRNGs has already heard about the Diehard tests and would have used these in preference, or as a subset, of subsequent testing.

<https://secure.wikimedia.org/wikipedia/en/wiki/Diehard_tests>

As may be expected Diehard isn't the be-all-and-end-all of random generator testing; NIST have their own standards. Dieharder is an attempt to consolidate Diehard, NIST, and various other randomness tests.

<http://www.phy.duke.edu/~rgb/General/dieharder.php>

This is a severe, severe case of "Not Invented Here"; please do research before reinventing the wheel.

<comment><AUTHOR> Just looking for a good enough solution that's easy enough to bundle into a small packaged sim. I'll review your recommendations, thanks for sharing them.</comment></comment>


Today's Techcrunch top news visualized in a mind map - <AUTHOR> http://www.memofon.com/public/screencast/pages/tech%20news%20mind%20map

<comment><USER2> Didn't seem to work for me: when I tried to move the nodes the whole diagram shifted rigidly.

<comment><AUTHOR> This is by design :) When you click node, diagram should be positioned to the center of the screen. When you move it with mouse, it should move as expected.

<comment><USER2> Oh. The site says you can "arrange" the diagram. I don't interpret "arrange" to mean shift position without changing the ... arrangement.

<comment><AUTHOR> You are right, my bad. I commited a bug in documentation :) Fixed now.</comment></comment></comment></comment>


A telescope will generate 10x more data than today's global Internet traffic - <AUTHOR> https://www.skatelescope.org/frequently-asked-questions/ <comment><USER2> "Just in its first phase, the telescope will produce some 160 terabytes of raw data per second"</comment>


America's Never-Ending Battle Against Flesh-Eating Worms - <AUTHOR> https://www.theatlantic.com/science/archive/2020/05/flesh-eating-worms-disease-containment-america-panama/611026/ <comment><USER3> This amazing bit from the wikipedia article about the fly:

"The first, and to-date largest, documented infestation of C. hominivorax myiasis outside of the Americas occurred in North Africa from 1989 to 1991. The outbreak was traced to a herd of sheep in Libya's Tripoli region, which began suffering screwworm attacks in July 1989; over the following months, the myiasis spread rapidly, infecting numerous herds across a 25,000 km2 area. Eventually, the infested region spanned from the Mediterranean coast to the Sahara Desert, threatening the more than 2.7 million animals susceptible to C. hominvorax that inhabited the area. More than 14,000 cases of large-scale myiasis due to the C. hominivorax species were documented. Traditional control methods using veterinary assessment and treatment of individual animals were insufficient to contain the widely dispersed outbreak, so the United Nations Food and Agriculture Organization launched a program based on the sterile insect technique.[10] About 1.26 billion sterile flies were produced in Mexico, shipped to the infested area, and released to mate with their wild counterparts. Within months, the C. hominvorax population collapsed; by April 1991, the program had succeeded in eradicating C. hominivorax in the Eastern Hemisphere. This effort, which cost under US$100 million, was among the most efficient and successful international animal health programs in UN history."

Incredible!

1\. [https://en.wikipedia.org/wiki/Cochliomyia](https://en.wikipedia.org/wiki/Cochliomyia)

</comment><comment><USER4> A little tangential, but having just been in an argument here with someone who advocated a "nightwatchman state," I wonder what they'd think of the USDA's efforts here (as well as the other governments'). It seems almost impossible that this could have been coordinated by private industry alone: while there's an obvious benefit to the cattle industry, it seems hardly likely that they would have sponsored the years of investment in basic research that led to this, let alone successfully negotiated with Panama for the rights to dump irradiated bugs from coast to coast. Could it have been done?

It's also striking how much these efforts were made _harder_ by US foreign policy and involvement in the wars of Central America, and are still made hard because of our poor relationship with Cuba.

<comment><USER5> > ...it seems hardly likely that they would have sponsored the years of > investment in basic research...

That is the easy part. There is a good model for shared infrastructure - <USER2> private corporation is established, all the local companies buy a share then the shared company builds, owns and operates the actual infrastructure. The same thing works for funding long-term research in everyone's best interest. A shared research corporation that all the local businesses can buy into. They can be guilted in to a small contribution and the research can happen at a slow-burn to generate results over time.

To me the bigger challenge is who would pay for dumping large numbers of irradiated bugs.

<comment><USER6> But this never happens?

<comment><USER5> I didn't come up with the idea, I saw it in action in a mining context.

Besides, how you can be sure it does or doesn't happen? The world is large and complicated; and basic research gets nearly no press and is very hard to statistically quantify. Where would you look for proof in the positive or negative?

<comment><USER7> Fonterra, New Zealand's largest company runs along these lines. It's a dairy company, so basically gets milk from dairy farmers and puts it on the market. It is a co-op owned by those farmers.

</comment></comment></comment></comment></comment><comment><USER8> > _Scientists now knew, from the horrific consequences of atomic bombs dropped > on Japan, that high doses of radiation damage human tissue and cells. When a > colleague introduced Knipling to research on the sterilization of other > flies by radiation, he wondered: Could radiation sterilize screwworms too?_

This is wrong, harmful effects of radiation on cells, that it causes mutations and makes things sterile, were known long before WW2: [https://en.wikipedia.org/wiki/Hermann_Joseph_Muller#Discover...](https://en.wikipedia.org/wiki/Hermann_Joseph_Muller#Discovery_of_X- ray_mutagenesis) They basically just put a lot of fruit flies under X-ray radiation and recorded the effects.

<comment><USER9> Well it's a classic journalistic technique. Put two statements adjacent to each other and imply a connection but actually you can see there is no formal conjunction.

<comment><USER10> I don't follow your logic.

The description " _from the horrific consequences of atomic bombs dropped on Japan_ " is written and reads as nonessential, meaning it goes without saying but is nevertheless helpful in qualifying how " _scientists now knew_ " within context of the article's chronological prose.

I understood the parent's remark as rejecting this factual inaccuracy.

<comment><USER9> There's not much logic in my statement just an understanding of what the journalist is trying to do: dramatize something quite ordinary.

They want to establish a historical context where Hiroshima was a recent event and somehow tie this highly dramatic event to the simple fact that scientists knew radiation damaged cells. But there is no particular connection between the two since scientists already knew that prior to Hiroshima.

So what's a hack to do? Well you write one sentence. Then you write another. You don't say "because". You just stick 'em close together. That way you get your cake (drama) and eat it too (can't be called out on a falsehood).

In this case your brain does the work for them and "joins" these two statements together. At which point if you know it's false you're aggrieved - and quite rightly because it is intended as a (mild) deception.

But it passes an editor because you can just say (waving hands) "well you know it was all happening around that time - I'm just filling in the general background..."

</comment></comment></comment></comment><comment><USER11> Great article. Wikipedia page is also interesting.

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

</comment><comment><USER12> I was just reading about these drone dispersed little paper balls filled with parasitic wasp larva used to control corn borer. [https://altigator.com/organic-agriculture-the-treatment- of-e...](https://altigator.com/organic-agriculture-the-treatment-of-european- corn-borer-by-dropping-trichograms-by-drones/)

</comment><comment><USER13> I wonder what would happen if instead of releasing sterile male screwworms, we used the gene drive to release screwworms that could only have male descendants. I've heard of a similar idea to eradicate malaria by doing that to mosquitoes.

<comment><USER14> It seems that the mosquito effort was not a success after all [0].

[0] [https://m.dw.com/en/genetically-modified-mosquitoes-breed- in...](https://m.dw.com/en/genetically-modified-mosquitoes-breed-in- brazil/a-50414340)

<comment><USER15> Different approach, that attempt was to reduce population sizes not cause extinction. Though it is evidence that Gene Drive is less likely to work than many expect.

<comment><USER16> Nature thwarts gene drives by modifying their targets, so it's important that whatever is being targeted can't easily change. Surviving instead of being killed off is certainly an evolutionary advantage, after all :-)

There's been some research on finding targets that can't be mutated. Here's one example: [https://www.nature.com/articles/nbt.4245](https://www.nature.com/articles/nbt.4245)

<comment><USER13> While that may be true for general use of the gene drive, doesn't this particular use significantly increase the fitness of the individual organisms (despite being harmful to the species as a whole), resulting in essentially no evolutionary pressure against it?

<comment><USER17> Evolution happens on all levels at the same time. So, while this is the most likely result, it's not impossible that things go in other ways.

Anyway, it's also very unlikely that those actions result in anything worse than resistance against those same actions in the future.

</comment></comment></comment></comment></comment></comment><comment><USER18> I really had no idea the sterile-insect technique worked so well! One wonders, as was chewed over in a thread a few days ago, why it isn't already being used at scale to destroy invasive populations of malaria-bearing mosquitoes in sub- Saharan Africa.

<comment><USER19> Maybe mosquitos mate more than once, making this type of program much less effective.

</comment></comment><comment><USER20> Very long essay but very good. it is the same technique they tried to use for other diseases. Not sure why evolution cannot fight it - female that can detect sterile male survive.

</comment><comment><USER21> I thought this would be about Carter and the guinea worm</comment>


Show HN: ToaruOS 1.0 – A complete hobby operating system - <AUTHOR> <comment><USER2> There are no links to the project (unless the post is updated), so I googled them:

\- [http://toaruos.org/](http://toaruos.org/)

\- [https://github.com/klange/toaruos](https://github.com/klange/toaruos)

<comment><AUTHOR> Unfortunately there is no option to add url afterwards. The Github URL is: [https://github.com/klange/toaruos/releases/tag/v1.0.0](https://github.com/klange/toaruos/releases/tag/v1.0.0)

<comment><USER3> The current discussion: [https://news.ycombinator.com/item?id=13529056](https://news.ycombinator.com/item?id=13529056)

The idea of 'Show HN' is for people to post projects that they've created themselves, regular submissions are people showing HN cool stuff other people have made.</comment></comment></comment>


Space Based Radar Geolocation - <AUTHOR> https://threadreaderapp.com/thread/1217505788974989312.html <comment><AUTHOR> two more informative threads (scroll-up)

[https://twitter.com/M_R_Thomp/status/1217510002723893250](https://twitter.com/M_R_Thomp/status/1217510002723893250)

[https://twitter.com/gbrumfiel/status/1217506180303663104](https://twitter.com/gbrumfiel/status/1217506180303663104)</comment>


Ask HN: How to visit Sand Hill Road VCs? - <AUTHOR>

I can't think of a better place to ask this question.
If one is visiting the bay area on startup business and has a few meetings with VCs on Sand Hill Road, how the heck do you get there and back?
I usually take Caltrain into the valley, but most of the VC offices are 3+ miles from the Palo Alto Station (~40 minute brisk walk each way). Is there a bus (or monorail) on the Stanford campus that simplifies this? Do you ask VCs for carpool suggestions? Does Uber work in the valley?
How do other founders handle transportation to VC offices? <comment><USER2> Google maps can give you public transit directions including local bus services (Shuttle to Stanford, SLAC bus goes near SHR). This makes for a long, long journey compared to driving, but you can work/think instead of operating a vehicle.</comment>


Show HN: Auto blur photo background with so many beautiful effects - <AUTHOR> Demo: https://youtu.be/RjNlsdInQIs <comment><AUTHOR> For more info, please visit our website: [https://quickblur.codolife.com/](https://quickblur.codolife.com/)</comment>


Inventions still need a human touch - <AUTHOR> https://www.ft.com/content/cc2f8b0a-a01e-11ea-ba68-3d5500196c30 <comment><AUTHOR> [https://archive.vn/Tnco2](https://archive.vn/Tnco2)</comment>