Hacker News Reader

Comment by avereveard | Hacker News Reader

The reason this happens is that management is secretly hoping that using a process will allow them to do get by with junior developers because the software complexity will be magically handled by "The Process"

I honestly don't blame them for trying to industrialise software production, I blame the engineers which is probably the only white collar profession that don't care about being in control of their own field narrative

View on HN

This was readily apparent at my last shop when we had a range of junior (months out of college) and seniors (20+ years experience), and the expectation was simply that seniors were to clear more tickets/points per sprint.

We didn't allocate more architectural tasks to seniors, or pair them with juniors, or give them long running slices of work across sprints.. we just were like "more points please".

We ended up with under-engaged seniors all leaving, and juniors being given tasks they couldn't accomplish.

This has been a very underappreciated point in all companies I've worked for so far. The difference between an good programmer and a bad one is not (just) that the good one is faster, it's that they can solve problems that the bad one cannot solve at all.

The terms "junior", "senior", etc make it appear as if the latter is just an older version of the former, but the correlation between work experience and actual skill is far from 100% in my experience.

I use senior here also to point out - we had a team composed of people who had literally built a similar/same system elsewhere, and kids who are working for a living for the first time in their lives for a few weeks.

The idea that everyone gets a vote on story points & planning meetings in a conference room for hours&hours, while democratic, is counterproductive.

Further, as it turns out, the dev who has done the thing 2-3 times before knows all the mistakes not to make, and move onto make new & unique mistakes (joking, sometimes) whereas the junior gets to make all the mistakes all over again.

The senior is always going to give a higher effort estimate, but will generally be able to accomplish the task within that estimate more often.

A junior has no ideas what they don't know, and can often be off by orders of magnitude on their estimates. Usually because they consider only what is required for the "happy path" of the code to work as expected when used as expected, with no bad data/etc. Further they will include the time it takes them to get the first cut of the code working on their box, undocumented, uncommented, not in git, not tested, and not ready for release.

Yeah, that's another thing... Because good developers are rare, expensive, and risky, corporations think they can get the equivalent work output of one good developer by lashing together several average developers the way you can get effectively one large reliable disk by RAIDing together several smaller, less reliable ones. This in and of itself is a strong motivator for how agile is done in corpo shops.

Of course, the fact that programmers don't actually work that way is something these corporations' management didn't get the memo on...

programming computers is a blue collar job. like a machinist or a welder. probably half of the work is fixing defects.

I know machinists and welders. Some of them just want a blueprint and will make what you want to that spec. Some of them want to be told "make this part fit on this other part", and they get to make up the bracket that fits. There is a place for both. One is basic and easy to automate - but often it turns out the costs of setting up automation is higher than the cost of paying someone to do the production run. The other is hands on engineering and needs some engineering knowledge.

Can you put programmers in a production line and expect quasi linear improvements?

No.

Because programmer jobs have a knowledge and creativity bottleneck, that is the hard part to scale, and require workers that have autonomy, can take initiative, and can put together a solution from known part in ways that create solutions for one off problems.

Metaphorically speaking they are not tightening the same bolt type over and over again to the same spec every time. Software is not manufactured, it's largely artisanal.

I think those defects often come about because the rest of the process emphasises schedule over quality. It’s a false economy, but many businesses treat quality as a cost rather than a benefit.

It is again one of the problems with scrum. There is pressure to complete a feature in a given sprint - and a sense of failure if you don’t.

Reply on news.ycombinator.com