Live data from Hacker News

Individuals Matter

danluu.com

341–350 of 419 posts

Re: Individuals Matter

#341

This is also why I really love working with software, because it's one of the greatest force multipliers on the potential impact of an average individual I can think of. We don't have to be once-in-a-decade level genius visionaries or hire a gigantic team with millions in funding to build something that can make the lives of millions of people tangibly better, while capturing some/most of that value in return to impr…

> build something that can make the lives of millions of people tangibly better,

That's why the brightest minds of a generation are dedicated to making surveillance advertising more effective.

Re: Individuals Matter

#342
post #82
post #29

Earlier quoted context omitted.

Devs: there are no 10x engineers!! Orgs: okay you are indistinguishable cogs and we will treat you as cattle Devs: no wait not like that Truth is everyone knows that who or which teams takes a task matters immensely. We know that if Bob leads it’s gonna suck and if Alice does it’s gonna rock and finish on time. Managers know this also. But we’ve constructed a corporate culture where this is not allowed to be said. So…

Not only are there 10x engineers, I personally know an objectively measured 500x engineer. He is humble because he knows someone who produces 10x what he does (albeit spending twice as much time at it). The measurement happened as a result of a joint venture between Siemens AG and Ericsson called Ellemtel. Each company sent 250 [edit: not 500] engineers. It was a six month project, the classic death march: if it did…

Assuming you can objectively measure someone like this, either by LoC or delivery times, this is the wrong way to approach any project.

Having a 10x engineer(or even worse, a 500x engineer in this alleged case) is a huge risk for the company, should the engineer want to leave or if they are incapacitated in a tragic event, the company is severely handicapped, ideally a so-called 500x engineer should spend less time writing the actual code and instead mentoring/managing others to scale up their knowledge, should the company do this right, they might not deliver on time, but they'll have a much wider array of experts when something breaks or for the next projects, reduces overall company risk and it's more profitable in the long run.

Re: Individuals Matter

#343
post #116

I am a security engineer but have been a business leader from time to time. Business leaders often need to plan around dates- eg ”should we spend $50k announcing at conference Y in month Z, or should we wait until month A?” “Our competition just launched; will we be able to launch this quarter (the board wants to know, and we have to report material financial impact items quarterly or face SEC fines)?” Every team I h…

Stop using methodologies actively preventing any kind of planning (mostly agile stuff). Return to waterfall, write lots of documentations, spend time planning architecture, resist urges to rewrite non-ideal solutions. Do not allow changes. It'll take more time and result will not be as clean. Basically learn from older engineering disciplines.

Also, build several prototypes of every important part of the product in order to learn how long they will take to be made and how each variant will perform, so when you make estimations they are as effective as possible; and then, make integration tests on the selected variants so you can reduce estimation risks due to integration. Just as in every other engineering discipline.

Re: Individuals Matter

#344
Another way of saying this is "Don't use process to overcome people problems". I've seen a lot of dysfunction because the org chooses to put a heavy process in place because 1 or 2 people made obviously bad decisions. It then punishes everyone for the acts of a few, and usually is done because the org isn't healthy enough to give those people feedback or let them go.

Re: Individuals Matter

#345
post #87

Earlier quoted context omitted.

Some of the most capable people I've ever worked with have been "bursty" in that they would go through intense periods of high value output and then need to almost go dormant for a while to reset. As long as the "high value" phase was uniquely and significantly valuable it wasn't a problem so long as management understood and planned their assignments appropriately.

Not to lean too much into my armchair, but the phenomenon you describe sounds like some mild form of bipolar. Periods of very high output, and then periods of slump. Not much of a long term stable in-between. I wouldn't be surprised if that's very effective for the right kind of project.

I am bipolar and this is completely wrong. People have variable output. Motivation comes and goes. Live circumstances change. People burn out.

These are not bipolar. The name "bipolar" is very misleading. One book I've read has called with multipolar disorder, which is far more accurate. There isn't just mania or depression. There is a whole world of possible dysfunctions that come with it: Anxiety, ADHD, insomnia, psychosis, and the list continues. There can be different moods, stages, and flavors of mania and depression in one person!

On top of this, these symptoms need to be severe enough to impair normal daily function to be diagnosed.

Re: Individuals Matter

#346
post #161

Did we ever figure out why he wants the computer that comes in the smallest box?

Can you not just imagine? Luu: "I want the computer with the smallest box" Sales rep: "Boxes are nothing to do with computer performance" Luu: "I understand. Still, please humour me?" Rep: "But there are sneering people on HN who think you think you're better than them. Somehow this should be important to you" Luu: "Anyway, moving on, I want to buy a computer" Rep: "No. Not until you explain." Luu: "Fine, I want to s…

>Can you not just imagine?

Of course I can, but I want to hear the horse's reason from the horse's mouth.

Re: Individuals Matter

#347
Individuals do matter but outside of their immediate manager no one has knowledge, time, or attention span to account for it. It is a case of "all models are wrong, but some models are useful" and this is why sufficiently high level plans and budget allocations follow the assumption of fungibility.

Re: Individuals Matter

#348
This conversation makes me wonder: has there been any halfway decent quantitative research on estimation methods?

I've lived through what seems like the de facto agile standard: you take some piece of work, and estimate it out according to a point scale, assuming the "average" dev does the work.

Curious to know now if it has any effect on project timeliness. Or are these estimates generally "vanity metrics" in practice?

Anecdotally, they are generally pretty useless for planning unless they are at a very fine grained level, with low complexity, on an extremely well-understood piece of software.

Re: Individuals Matter

#349

Earlier quoted context omitted.

So y’all don’t disagree with the main point. There are some specific individual engineers who will get a specific individual task, faster than some other specific engineers. If those same specific engineers get done many general tasks faster than another group of specific engineers on general tasks than they are just better in general. If some other specific task gets done by the other specific engineers better then…

So a fast programmer is necessarily better than one who takes a little more time but pushes out stabler code?

Touché, same quality just one done twice as fast let’s say. Just a hypothetical.

Re: Individuals Matter

#350
post #329

Earlier quoted context omitted.

TIL: "Winston W. Royce's final model, his intended improvement upon his initial "waterfall model", illustrated that feedback could (should, and often would) lead from code testing to design (as testing of code uncovered flaws in the design) and from design back to requirements specification (as design problems may necessitate the removal of conflicting or otherwise unsatisfiable / undesignable requirements)" https://…

This is a good article on the topic http://www.bawiki.com/wiki/Waterfall.html

That is indeed a Great Writeup!

Instead of getting lost in the comments, You should post it to HN and invite discussions with a title like "Most of what you have heard about the Waterfall Development Model is Wrong!" or "How the Agile folks have misled you about the Waterfall Development Model" :-)

Post reply on HN