Live data from Hacker News

Individuals Matter

danluu.com

351–360 of 419 posts

Re: Individuals Matter

#351

Earlier quoted context omitted.

> I think I'm going quite slowly because I'm having to learn a lot, and I don't think I'll deliver this in 3 days Their first question after you say this will be "well, how long will it take?" Whether or not you actually have any idea how much time you'll need, you'll have to give an answer, and on that blows the schedule up too much will be strongly frowned upon. Now you've realized you're working for a crappy PM/EM…

That is a function of time in company and continuity of team more than skill of manager.

I disagree. I think skill of manager plays into it more than anything. I've seen managers come on board and within 3-6 months were able to operate like this. They focused on learning the technology and getting to know the people before they started actively managing. These were large, long running teams they were joining too.

Re: Individuals Matter

#352

Earlier quoted context omitted.

Totally irrelevant and no Ad Hominem please. FYI, D.L.Parnas and Barry Boehm defined the field of Software Engineering. Almost all Govt./DoD standards are based on their research and writings.

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://…

Most books on Software Engineering are mere compendiums with nothing much to recommend them eg. the texts by Sommerville or Pressman. Two exceptions that i know of are those by Ghezzi,Jazayeri,Mandrioli and Pankaj Jalote.

Re: Individuals Matter

#353

Earlier quoted context omitted.

The PM proceeded to take an estimate from this person, hand it to a brand new hire, and expect them to deliver on that. Needless to say it could have gone better for me. This is a really good thing to learn from, although I doubt it felt like it at the time. The key thing that every junior dev needs to take from it is that it's fine if things don't take however long the estimate is so long as you're regularly communi…

>>> Practically all the actual work a PM does is communication. Practically all the actual work a PM does can be replaced with a script and dashboard

For small tasks, yes this works. For larger feature work that involves cross-team collaboration, including legal, security etc, a pm is a godsend.

Re: Individuals Matter

#354

Earlier quoted context omitted.

Practically all the actual work a PM does can be replaced with a script and dashboard That is entirely true if you have an organised, disciplined dev team that communicates well. Good luck with that.

This isn't true even with a organized, disciplined team. What happens is the responsibilities of get divided out to other people on the team. Usually not the entire team, so some people are stuck with unacknowledged overhead.

Unacknowledged overhead happens even with a PM present. Usually it's work that is absolutely critical to getting a project done but a PM would tell you it's a waste of time if you brought it up with them.

Re: Individuals Matter

#355
post #124

Earlier quoted context omitted.

I got a harsh lesson about this in one of my very first jobs. A senior engineer on my team had built a rather complicated system. He was accordingly intimately familiar with all aspects of it. So when he estimated something on that system, it came with nearly all the discovery work already done. The PM proceeded to take an estimate from this person, hand it to a brand new hire, and expect them to deliver on that. Nee…

That engineer is Senior in title only. Unfortunately this is a common pattern - a mid-level developer will play "hero", make a mess that only they understand, and - if given the title/responsibility by immature management - proceed to royally screw their team. Actual Seniors have the experience and foresight to handle this properly. Either build code with enough documentation/tests that others can understand it, or m…

Up to speed on their way out the door if they have any self esteem at all.

Re: Individuals Matter

#356
post #87

Earlier quoted context omitted.

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.

>some mild form of bipolar Please no; we don't have to stigmatize normal waxing and waning of mental/physical energy. There are a lot of "normal" factors involved in any Individual's productivity and pathology should be consulted only as the last resort.

Thank you. Everyone has up days and down days. Some of them can even be kind of extreme like not wanting to get out of bed. Variation is normal, we are not robots.

Re: Individuals Matter

#357

Earlier quoted context omitted.

The corporate culture serves a very specific purpose of lowering the self-esteem of the 10x folks, keeping them at their place doing 10x work at 1x salary until they burn out. This is scalable, predictable, and serves management's interests well. It's just if you happen to be a 10x guy, for the sake of your own sanity, learn how to run a business and get out of the corporate swamp. Nothing else will bring you happine…

Isn't it insane that there are many 10x engineers who have created enormous amount value (creating patents, leading and executing projects, innovating etc.); Yet, the world will only know about the company or the CEO and never the engineers behind it.

How do you expect the world to know about the others? The CEO is public facing by definition of their duties and the charter. Any other public presense from the organization technically falls under marketing of some sort, even teaching useful generic skills for free (say a publisher promoting literacy in third world nations) is in service of this.

It requires looking into arcane details to know about the engineers behind it. I mean software, especially media productions often include outright credits but few would remember any but leads usually. Precise attribution would get downright absurd in a pure data sense to give coverage that few care about. Say for just a simple who tightened the screw on this part of the cloth mill during its production run, who made the screw, who farmed the cotton, made the irrigation means....

Replicability and productivity atr what leads to technical obscurity ironically - because the automation and scale means fewer people are even in the position to know what to even ask about the details relative to the numbers served. Thus the knowledge remains arcane. Not many people would even know say, that DRAM tries to minimize capacitance and inductance but it needs some of both to function. Let alone who was involved with what subsection of the chip design and design testing process.

Re: Individuals Matter

#358

Earlier quoted context omitted.

This is how planning should be done. Gauge people's expertise, put them on the path they can be most effective and then ask for their estimates. Take that to upper management and negotiate.

One problem with that is sometimes the estimates are done long before the work starts so when that item eventually gets to the top of the priority stack the person estimated for is working on something else instead. At this point things need to be re-estimated which can cause friction if the new estimate is longer (“but last time, you said…” or “when we asked Bob, he said…”). What I've done in the past is give an est…

> things need to be re-estimated which can cause friction

But, but ... isn't every estimate supposed to be provisional? Aren't you supposed to be re-estimating regularly?

Re: Individuals Matter

#359
post #82

Earlier quoted context omitted.

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…

> 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). So your 500X engineer knows a 5000X engineer and he wrote as much code as 999 other engineers combined? (That would make him a 999X engineer, FWIW) A 500X engineer (per your measurements) would have to write 500 lines of code every day without fail,…

The multipliers are all relative and seldom in simple metrics such as lines of code. If you wanted to inflate the numbers in a technically truthful way stick in a complete novice capable of preparing (so they are not negative) but not prepared for a complex field so their multiplier will be low. Use them as your 1X and even burnt out and demotivated employees who don't stand out could wind up performing 50x relative to them.

Re: Individuals Matter

#360
post #82

Earlier quoted context omitted.

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…

This really isn't my experience with super productive engineers. Usually they're solving high level technical problems for the company that most employees wouldn't touch with a ten foot pole. It isn't the raw LOC they produce but their ability to translate complex technical problems into elegant solutions for everyone else to take advantage of.

The Death March is not a usual circumstance. In usual circumstances, different practices are indicated.
Post reply on HN