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.
Individuals Matter
351–360 of 419 posts
Re: Individuals Matter
#352Earlier 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://…
Re: Individuals Matter
#353Earlier 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
Re: Individuals Matter
#354Earlier 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.
Re: Individuals Matter
#355Earlier 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…
Re: Individuals Matter
#356Earlier 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.
Re: Individuals Matter
#357Earlier 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.
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
#358Earlier 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…
But, but ... isn't every estimate supposed to be provisional? Aren't you supposed to be re-estimating regularly?
Re: Individuals Matter
#359Earlier 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,…
Re: Individuals Matter
#360Earlier 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.