Hacker News Reader

Comment by treerock | Hacker News Reader

To use your example the workers can generally just turn up and work. The bricklayer doesn't have to be concerned with the carpets. The joiner doesn't have to worry about zoning restriction.

I'm curious if software development (in large organisations) will ever reach that level of specialization, where a coder will be able to 'just code', because others workers will be employed to handle everything else.

View on HN

I think this actually does happen to some extent. The larger an organization and longer it's been around, the more likely it is that some people on the team spend some or all of their time working on tooling for the rest of the team. When done right, this means that most of the team members just need to follow some well documented or automated process to get fully up and running, and never need to really think about all the moving parts.

This is a great point. How many 'full stack' builders do you find ? They obviously exist, but would generally fall under the 'handyman' moniker, which is maybe equivalent to a 'hacker' ?

Unfortunately, the world of software development seems to have been pushed away from specialisation and each person knowing certian topics well, into 'everyone is just a resource - anyone can code' mindset.

It does get there already, in some places. I've been in large organizations that have a build person, a source control person, etc. They take care of it all, so the coders can "just code".

Those environments have totally sucked, because to pigeonhole people into those roles in the first place requires a non-flexible, non-creative culture.

There is a proper balance to everything, but few organizations succeed in finding it.

>a source control person, etc. They take care of it all, so the coders can "just code".

What do you mean a source control person, just someone who manages the source control when it goes wrong? The programmers are still doing the committing, pushing, pulling, branching themselves

Committing yes, everything else no. The source person managed the servers, branched and merged as necessary, and oversaw the build processes to be sure we had good dev, test, UA, and prod deployments at any given time.

She hated that job, BTW. :)

I was fascinated with Brooks' proposed "head surgeon" solution to the coordination problem for large projects - basically (and forgive me if my summary butchers this a bit), instead of having 1000 programmers on one repo arguing, you have a smaller number of vertically-integrated teams with a "head surgeon" at the top of each, and it is the head surgeons who have to coordinate. (Needless to say, the "head surgeon" has to know how to code pretty well and be significantly involved in the project rather than hovering at 20,000 feet...)

I guess most people would only like to be the "head surgeon" because of the implied status (and not really knowing what it is like to be e.g. Linus Torvalds). But personally, I wouldn't mind doing a specialized job like the tools programmer or language lawyer because these are still interesting jobs allowing good forward progress to be made.

If the load of tedious work like build systems is too much, and the best we can do is either load-balance it across the team or dump it on some schmuck, maybe that just means we should try harder to break up projects into smaller units so that process doesn't completely dominate them.

Let's push this:

Before any carpet or brick is placed, a foundation needs to be poured, but before that, a hole must be made, but before that, a machine must be purchased. Then, someone is going to ask: "how big should the hole be?" And the answer would be, "Whatever, I am just going to put these bricks on it."

and the whole thing just falls apart because nobody can just lay bricks.

Reply on news.ycombinator.com