Hacker News Reader

Comment by jdbernard | Hacker News Reader

> they definitely need at least a year before they understand the problem space well enough for their offers of major architecture changes to be welcome.

No offense intended, because I don't know your situation, but as someone who has worked in several industries, every time I've heard that kind of phrase it's boiled down to some combination of unnecessary complexity (of architecture and/or process) and undocumented tribal knowledge.

I can't imagine any problem space that would take a senior developer a full year to become competent.

View on HN

Competency != suggest major changes to architecture.

In fact suggesting major changes to architecture is a strong signal of an immature developer. There are times when major changes in architecture are warranted, but they are suggested far more often than that. The implications of the suggestions usually mean rewriting lots of code just to stand still.

Precisely this, thanks!

Why would it be ok to suggest changes after a year then (which is fairly arbitrary btw), according to that logic?

TBH, I'd only suggest changes when they are really required (i.e scalability issues, maintenance issues, etc) but that has nothing to do with how long I've been working in a project. Requiring a year of knowledge about the domain is nonsense to me.

> I can't imagine any problem space that would take a senior developer a full year to become competent.

I am somewhat arbitrarily latching onto your statement as a place to respond. But my thoughts are swirling around many other posts in this whole thread... I think "problem space" conflates too many different aspects of real world work which can all require significant time to comprehend as a new member of a team.

Any non-trivial project must include hysteresis in planning and management, meaning that an architecture encodes a number of economic decisions and strategic positions. Hardly anybody would look at a long-lived project and declare that they would build it the same way if starting from a blank slate that day, but this is irrelevant when considering overall engineering costs and risks. Things must be far worse than "not ideal" before it makes sense to invest in rebuilding existing functionality rather than maintaining it.

Secondly, the actual "problem space" is what gets assigned to subject matter experts in very large organizations but must also be understood by those making engineering decisions. I don't think that there is such thing as a "senior developer" who can waltz in and start declaring how to solve problems without learning this subject matter, and it can certainly take years to acquire such expertise. You can't just know how to build things to spec, but must have an appreciation for which things to build, and what business purposes are being served. Often, a worthwhile rearchitecture is not simply refactoring the code that performs the same thing, but refactoring the entire solution to address subject matter problems in an entirely different way. Sometimes, the subject matter is highly technical (like physical problems, or logistical optimization, or machine vision) and sometimes it has much larger social components (knowing the customer/user and their requirements or limitations).

Finally, there is a third space of expertise which gets to the heart of some complex projects. A deep understanding of how an engineering organization functions and of its members can be another realm of subject matter expertise. You can't appreciate the economic and application decisions encoded in the architecture if you aren't aware of the strengths and weaknesses of the team. Sometimes, a senior person with deep technical knowledge can be faced with the worst truth of all: a better technical approach that you are well acquainted with is simply inappropriate for a project that does not have the staff nor the will to build and maintain it. Decisions are hardly ever so modular and independent that we can satisfy all participants without compromise.

I have never worked in any problem space where it _wouldn't_ take a senior developer a year to become fully competent.

Unless by "Senior developer" you mean someone who already has experience in the problem space, of course. If all you do is ecommerce, then, sure, you're already competent at ecommerce (at least hypothetically you could be) because you've already spent more than a year at it.

> I think "problem space" conflates too many different aspects of real world work which can all require significant time to comprehend as a new member of a team.

I agree. I apologise because I don't have the time to give you a proper response. Most of the things you are talking about that are things that transcend specific problem domains and can be learned over the course of many years in a career. The point I'm driving at is this: a "senior developer" should have already learned most of this and be and to apply it quickly to new environments. Very few things, and very few situations are truly unique. The same patterns surface in most of these teams/products/problems.

I don't expect a senior developer to necessarily be able to become a SME within a year (though for many domains that is well within the range of possibly). But I do expect a senior developer to be able to able to successfully design software systems alongside a SME within a year.

I am not so arrogant to claim to have seen every possible situation, but I have been around a fair amount and every time I've seen companies with "unique problems" that "take years to understand," it's been the fault of unnecessary complexity, regular miscommunication, or too narrow of a view. One company, for example, had spent so long staring at their own version of the problem that they were unaware of how similar it was to other problems that had already been solved.

One of the main skills of a good developer is the ability to decompose problems and create abstractions. It's one of the main benefits of some of the algorithmic courses you'd take in a CS degree: a survey of what is computable and the broad lay of the land that computational problems fall into. Of course, it can take several years to learn how to apply that knowledge, as well as all of the not-technical skills you mention above. But based on my experience I would guess that the majority of companies that think they need years to train people up in their domain either don't really have an understanding of software or don't actually have a firm understanding of what they are doing. Things are hard to teach because they're fundamentally not well understood by the instructors, not because they are fundamentally hard to understand or learn.

I started working in finance (fixed income derivatives) about a year ago, and i'm still getting my head round the domain. There are certainly some things i understand now, and i have a rough map of the space, but there's a lot i don't know, and a lot of important stuff i don't have an intuitive feel for yet.

Reply on news.ycombinator.com