Hacker News Reader

Comment by barrkel | Hacker News Reader

I don't really buy the analogy.

Writing software is a bit like playing multiple sports. You can be good at one thing and poor at another, and as a result do great work on one project and be mediocre on another.

Writing code in the small, optimizing; architecting for change; architecting for scale in development; architecting for scale under load; architecting for scaling out vs up; all different skills.

Writing code functionally, vs procedurally, vs message oriented. Writing code with control flow vs data flow, and toggling between them. Crafting abstractions vs composing them. Many small parts put together elegantly vs one straightforward transparent monolith. Some skills are alternates, you can go either way and get as good results.

There are people who only know a few things. But on a suitably scoped project, that may be fine.

View on HN

Sounds like you're contradicting the analogy but not the main point.

Many people would be completely happy with bowling a 160. In many contexts that's a great outcome.

But if you as a developer want to break past the equivalent stage of (beginner) expertise in any of the possible specializations or fields, you have to understand how to keep learning past the "know enough to be dangerous" phase.

Many developers stop at one paradigm and avoid stretching themselves further out of discomfort. Other developers learn a new paradigm but never reach the point of understanding its limitations, while having convinced themselves that they're an expert on that paradigm. From what I've seen it doesn't really matter which paradigm, language, toolset, or discipline you're talking about, this particular behavior happens all the time, and it matches the "expert beginner" label pretty well.

To be fair, the very first line in the OP says they don't buy the analogy, not that they don't buy the main point.

It wasn't obvious to me that it was purely about the analogy:

There are people who only know a few things. But on a suitably scoped project, that may be fine.

That's sort of a counterpoint to the main point, which is why I wanted to pull the discussion back to the main point.

Correction: not different skills: some of these are domains and subdomains; others are approaches; others are approaches and (sub)domains. They are all mixed up in your answer, which I found to be very insightful, by the way.

Although I am admitedly far from an expert in the field in question I am not a layperson either. I say the types of activities you mentioned are of the same group of skills, in different domains, which often requires a different but similar set of approaches (based on both convention and the subtleties of the domain).

For instance making wrist watches, grandfather clocks, steam punk sex dolls, and the ankagathera(sp) machine are different use cases and require different types of mental projections and organizational methodologies in execution (approaches), but the skillsets have an undeniable amount of overlap. They overlap more with each other than they exclude. In SQL terms the size of the output of the inner join is much greater than the same for the outer join. Therefore you can say that they are of the same skill set, just like doing abdomial flexibility helps with running and bicycling hill climbs helps your breast stroke. Different muscle groups, but share many types of synergy: all part of physical fitness.

Source: 10 years as a learning specialist in business setting and aspiring triathelete.

nicely put

and it doesn't contradict the article. If you have always worked in one paradigm and think you are an expert in it, learning new development skills can make you see you were not that good in your previous area.

I don't really agree with your characterization.

I consider the most reliable evaluation of expertise is working code. Something can be beautiful, but if it doesn't work, or doesn't solve the business problem, it doesn't count. If something objectively scales, I believe that the people responsible for building it are able to build that thing that scales.

If those people learn new things, they might learn how to do the job better. But maybe better isn't what the business needed. Maybe it would be better to invest that extra talent in something else, and hire people with the original skill level (who may be cheaper) to do the original thing.

This all might sound like an apologia for not learning new things, or limited developers who can only build a few things. In some ways, indirectly, I'm arguing against an unfounded arrogance or feeling of superiority which is driven by following the fashions of programming as a pop culture. But more of what I'm trying to get at is that the "best" isn't actually required, a lot of the time. And sometimes the best can be the enemy of the good; doing things the "right" way, according to an orthodoxy, can actually interfere with getting things done. And newcomers to orthodoxies can be - usually are - the most religious.

I've seen (and wrote) ugly code that does work, but I do not think I ever saw a beautiful code that does not work.

I've seen LOTS of beautiful code that doesn't work... in the real world, usually because it doesn't check the assumptions it makes. Is the data what is expected? Do the code's parameters span the space they should? Does the code inform the user of errors usefully and gracefully? Is it well documented, intuitive?

In my experience, when it comes to code, beauty and durability are natural enemies.

Then you probably have a different definition of beauty, because to me, beautiful code does check assumptions it makes.

100%

Reply on news.ycombinator.com