Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Individuals Matter

danluu.com

Post reply on HN
Print view View original

311–320 of 419 posts

Re: Individuals Matter

#311

Post by ChrisMarshallNY »

zshrdlu wrote: post #302
ChrisMarshallNY wrote: post #296

I tend to enjoy the topics that Dan Luu discusses, but his "wall o' text" presentation can be somewhat intimidating. It's better on a computer, than on an iPad. He's absolutely correct. I'm not sure that anyone in the industry (that can do something about it) cares, though. Nothing will change, until C-suite pocketbooks start getting impacted. As long as people are willing to pay for the type of software generated by…

What do you consider to be crap?

I won't actually get into that.

The reason being, is that I have made it a point to try to keep my [public] criticism to my own work.

I tend to hold myself to a fairly high bar. I'm quite aware that the level of Quality that I expect from myself is usually considered "commercially infeasible."

I'm OK with that. It's never been about the money, for me.

You are more than welcome to look at my [highly accessible] public portfolio, to see what kind of work I do. Check out my HN profile. I am not anonymous.

Re: Individuals Matter

#312

Post by astura »

Kalium wrote: post #124
paxys wrote: post #5

"Who is going to do it?" is always my first question whenever I am asked to estimate a piece of work. PMs/EMs are usually taken aback by the response, as if we are all supposed to pretend that all dev "resources" are equal. Yet reality doesn't fit into neat planning spreadsheets or burndown graphs, so often gets ignored.

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…

This is just extremely (almost comically) bad project management - nobody should take a senior engineer's estimate and apply it to a new hire or jr engineer.

I've never been a PM but from my planning discussions with mine all have adjusted for seniorness, familiarity with the codebase, and skillset. When I give an estimate I am only asked to give it for myself, it's the PMs job to adjust.

I guess I've been lucky because I've never had a PM that did that poor of a job. Maybe because it's because I've almost exclusively worked at companies that provide work to a paying customer, because that environment really depends on good project management.

Re: Individuals Matter

#313

Post by lifeisstillgood »

onion2k wrote: post #282
Kalium wrote: 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…

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

Re: Individuals Matter

#314

Post by onion2k »

lifeisstillgood wrote: post #313
onion2k wrote: post #282

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

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.

Re: Individuals Matter

#315

Post by bdavis__ »

mostertoaster wrote: post #187
fitzn wrote: post #119

Earlier quoted context omitted.

Measuring programming progress by lines of code is like measuring aircraft building progress by weight. - Bill Gates

And I bet an in progress airplane that weighs a 1000lbs is further along than an airplane that weighs 1.

Note this applies to the manufacturing,not the design.

It is actually a wonderful analogy with software:

* to a first order, cost of the materials in an airplane are proportional to the weight * at design time, the weight of the aircraft is minimized. thus, political and management forces cannot change it.

just like software, each subsection that is bolted on has different weights; but if you average it out it is a good measure of progress. and cost.

Re: Individuals Matter

#316

Post by tremon »

fitzn wrote: post #119
PragmaticPulp wrote: post #88

Earlier quoted context omitted.

> 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,…

Measuring programming progress by lines of code is like measuring aircraft building progress by weight. - Bill Gates

It's a nice aphorism, but it's a very bad analogy. Before the build of an aircraft is started, the target weight of the assembled product is (roughly) known. Therefore, in the process of building an aircraft, the assembled weight at least goes up from 0 to $target -- in an erratic fashion, but it's still a continuous measurement.

I have never seen a program design specification that even attempted to quantify the lines of code of the end product, let alone be accurate.

Re: Individuals Matter

#317

Post by mhb »

hyperman1 wrote: post #260
jseban wrote: post #231

Earlier quoted context omitted.

Yeah why do people have this view on programmers I just don't understand, every other single effing job in the world requires training and ramp-up, except programmers? And the fact that programming is depending on a unique pre-existing really complex code base further speaks against this. When my product owner quit, the new guy was working in parallel for 2 months to learn the ropes, noboby bats an eye, but a program…

I think they underestimate the value of specific knowledge. A builder that can build X meters of wall every day van do that reasonably independent of the building site. X will of course vary when you give a new kind of stones. The problem with programming is every job has its own kind of stones.

And they overestimate it when writing job ads.

Re: Individuals Matter

#318

Post by BobbyJo »

onion2k wrote: post #282
Kalium wrote: 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…

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…

> 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 who wants you to do their job for them, since they should have already known that the estimate from the first engineer will be nowhere close to the reality from the second.

The best managers I've had have been the ones that rarely need time estimates. They know enough about what's going on, and the comparative skill levels of the engineers, to give reasonable estimates themselves in most cases.

Re: Individuals Matter

#319

Post by chrisweekly »

perl4ever wrote: post #57
chrisweekly wrote: post #14

Earlier quoted context omitted.

> "This is why you never, ever take anyone seriously who thinks of society like a model." Yet that is precisely what classical economic theory has done, for decades! It boggles my mind how long it's taking for that kind of reductionist, simplistic, reality-ignoring "thinking" to mature.

"Reality" is necessarily a model. Your brain doesn't see photons, doesn't touch objects, doesn't respond to audio waves. If you are sane, then your model must not be subject to your will; therefore it is outside "you" even if within your skull, and performs as a trusted intermediary.

Sure, on that point we're agreed. Our perceptions (distinct from sensory input) are dependent on a conceptual framework / paradigm / model. But I didn't say models were useless, I was pointing out the profound flaw at the heart of typical economic models. Classical economic theory reduces the messy reality of human interaction to a handful of simple pseudo-mathematical axioms, then proceeds to build complicated formulas and algorithms atop this unreliable foundation. It's only quite recently that real-world complexity is (finally!) entering the picture, thanks to things like the Santa Fe Institute. It's reminiscent of the Copernican revolution.

Re: Individuals Matter

#320

Post by BenoitEssiambre »

hyperman1 wrote: post #260
jseban wrote: post #231

Earlier quoted context omitted.

Yeah why do people have this view on programmers I just don't understand, every other single effing job in the world requires training and ramp-up, except programmers? And the fact that programming is depending on a unique pre-existing really complex code base further speaks against this. When my product owner quit, the new guy was working in parallel for 2 months to learn the ropes, noboby bats an eye, but a program…

I think they underestimate the value of specific knowledge. A builder that can build X meters of wall every day van do that reasonably independent of the building site. X will of course vary when you give a new kind of stones. The problem with programming is every job has its own kind of stones.

I find that doesn't really capture the difference. In programming, the building part is fully automated. You press play or type a compile command and wait. If someone wants a build estimate, you should give them the time it takes to compile an deploy. Code is blueprint. Writing the code is all engineering, R&D, design and architecture and it usually entails figuring out how the system will interface with countless protocols, legacy systems, details of user's lives etc. It's nothing like building something that is already fully planned. It's a lot more like researching and planning all the details.
Post reply on HN