Hacker News Reader

Comment by mercutio2 | Hacker News Reader

It sometimes seems like we software developers travel in really distinct worlds.

People who have an established pattern of changing jobs every 2 years won’t even get an interview in my org, and 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.

The idea is that coming in and working on the problems you’re assigned is good because you can more deeply understand the problem space AND make things better.

I expect this, better and faster and with more humility and wisdom, from senior engineers. That doesn’t make anyone a ticket monkey in my book, it makes them effective at their very highly paid job.

As an aside, I highly recommend the article’s strategy for appearing (and hopefully actually being) wise and humble, as long as you’re getting your assigned, bare minimum work done.

Anyway, it sounds like maybe we mutually wouldn’t want to work with one another, which is why it seems like we live in different worlds to me.

View on HN

> 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.

I think there's a role for humility on both sides. In my current role, I was an experienced hire. After a month on the job my manager and his manager pulled me aside and said "What are we doing wrong?"

The interesting thing was that when I told them that I thought their module system was seemed backwards, the response was "Yeah, we know. It's a quirk of history that it ended up that way, and we've got a plan to fix it. Anything else?"

They very much valued a fresh set of eyes to ensure that they weren't missing something they had become house-blind to. At the same time, as a set of fresh eyes your attitude should be one of questioning, "Why are we doing it that way?" rather than "We're doing it wrong" or "This way is better".

Remember Chesterton's Fence.

Here's the trick: Every weird architecture exists for a reason, good or bad. If it looks wrong to a newbie, maybe the newbie misunderstands it, or maybe the business can't afford to build something better (and it's good enough as is), or maybe it really is wrong but the people who built it like it, so what good will come of you you trying to change it? Your newbie ideas only help if the veterans want new ideas and also your newbie ideas are better than their veteran ideas. That's possible but rare.

This is an excellent tool for the manager toolbox, thanks for sharing. Agreed that it’s great to get the fresh eyes benefits recorded/locked down.

The key is understanding that your teammates are probably pretty smart, you can learn a lot from them. You’re probably really smart, too, better to show your new team this with actions and quiet side conversations than showy pushes for unwelcome change, at least for the first year.

I do this every time we get a new developer, even a fresh-faced intern. Show them the basics of our project, turn them loose to go learn as much as they can, and then follow-up with "what did not make sense to you?"

Fresh eyes are incredibly valuable and you only get that once from each person before they become just as jaded as the rest of the team ;)

There's another facet to this story that's not getting discussed: that of path dependence.

The OP is Silicon Valley royalty. This matters. His site is pretty humble, but this guy was like, employee #10 at facebook and is probably worth high 8/low 9 figures. He is respected in a way most people aren't.

Boz can come in and start making these changes. Most people can't. We need to talk about this more. We labor under this bizarre illusion of non-hierarchical workplaces in Silicon Valley, when the reality is and always has been, some people have more influence than others.

I find it helpful to keep in mind the circumstances about the advice-giver as much as the advice itself. I'm not saying there aren't good nuggets of advice to glean. But who you are and your track record really matter in Silicon Valley and we should acknowledge that. It's not as much of a pure idea meritocracy as people think/pretend.

After a while I started thinking "flat org" meant "it takes longer to figure out who makes the decision."

After a while longer, I changed that to "regardless of the org structure, the org chart doesn't fully capture who has influence and who doesn't."

https://www.wired.com/2014/03/tyranny-flatness/

refers to the 1972 essay The Tyranny of Structurelessness by Jo Freeman. http://www.jofreeman.com/joreen/tyranny.htm

Nothing new under the sun.

The flip side of this is demonstrating humility and being a ticket monkey for a year, only to slowly realize you've been taken advantage of, and as you approach year #2 realizing that neither you nor anyone on the "ticket monkey" team ever has or ever will move to the new development group. I once had the experience of being duped by a company that (accidentally, or maliciously) advertised two Developer positions when in actuality they wanted one Junior Developer and one mid-level Developer. Our resumes ranked similarly so they arbitrarily put one of us on the ticket-monkey team and the other on the new development team. I should have either raised hell or gone elsewhere when I found out the level I received was not the one in my offer letter (the pay, while the same, was already below-market anyway), but like a chump I took it as a character building opportunity and thought I would work my way up. What I learned was that that strategy works in a dysfunctional company about as well as it works in a dysfunctional relationship.

> 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.

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.

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.

Precisely this, thanks!

> 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.

> at least a year before they understand the problem space well enough

I'm curious what domain you're in? I get the sense that different real-world topics account for much of the difference between developer 'worlds'.

I remember talking to a few rocketry companies in college (not SpaceX), and they were overt about wanting someone who would start out doing rote work and already had substantial expertise in their C package of choice. I certainly cant blame them; their risk profile is fundamentally different than almost any other software domain. (The exceptions, like military and aviation use, also tend to be pretty hard-nosed.)

"Not doing assigned work" is obviously a terrible trait basically anywhere, but the other divide here is really interesting to me. There are a lot of very successful companies which hire 2-year-turnover staff and assume they'll get the same, and then there are companies like yours with 'dark matter developers' who would never cross paths with that.

> People who have an established pattern of changing jobs every 2 years won’t even get an interview in my org

2 years? Most of the companies and projects I joined were long gone and dead 2 years down the road. Different industries indeed.

A matter of perspective. Everyone I have met with a cycle time of 1-2 years tends to be a low-value contributor. I get the feeling they move often because that's about how long it takes their team and management to conclude they aren't worth investing any more patience in. Some people only have interview skills.

But, I have not worked in a startup environment for almost 20 years so maybe in the right environment it is totally normal to expect people to jump around that often. I would advise being careful about keeping that up if you ever plan to move to a more stable part of the world because it is a stain on your resume.

> I get the feeling they move often because that's about how long it takes their team and management to conclude they aren't worth investing any more patience in.

Why would it take you 2 years to understand it about someone? In my experience, real figure is closer to something about 2 weeks.

In my experience people are pretty forgiving. At first you ascribe it to inexperience, unfamiliarity, etc. Eventually you decide maybe they just need to be coached because they seem otherwise competent. Then you put them on a plan. Then they leave before you drop the hammer. Maybe it doesn't take a full couple of years, but in a big company when you're busy with a lot of projects, it doesn't always move super fast. HR doesn't want us to fire someone because their is some risk and they know how much it costs to find someone new. My manager doesn't want me to fire someone unless they're truly irredeemable because there is no guarantee senior management will say yes to backfilling the position. It all adds up.

I haven't yet run across a valuable team member with a track record of short gigs, but I've run across several people who, in retrospect, clearly were just going from company to company in the area until they were too well known and then fled to another metro.

I can't speak for rootusrootus, but I suspect it may go like this: You figure out they aren't worth investing any more in, but they aren't worth the hassle and risk of firing. So you give them garbage raises. After a couple of years, they find greener grass somewhere, and move on.

> but they aren't worth the hassle and risk of firing

I'm so thankful that I'm living in one of the socialist european contries right now. Not being able to fire a bad contributor from my team would just make my blood boil.

>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.

IME, hubris usually correlates with architectural problems and higher than normal technical debt.

I can't see any good reason to analyze ideas about architectural overhauls on anything other than their technical merits. If there's a reason relating to the problem space for rejecting one particular idea that's fine, but unless your architecture is completely fucked that should be very rare.

It's perfectly normal to tear out the badly written guts of a software system and build up a better version, and a deep understanding of requirements should not really be required to do that in most cases.

Participating in conversations is great! Critiques should certainly be evaluated on the merits.

Precipitating new conversations with strong implication there’s a better way is less welcome. You can only have “we need to rewrite this” conversations about your core area so often per year before you get a jaded burned out team. New people should wait for those conversations at the team’s natural pace.

>Participating in conversations is great!

This phrase creeps me out. It reads like you're putting a thin veneer of "corporate happyface" over a heart of "STFU and do as you're told, children".

Maybe that wasn't the intention, but still... that's how it sounds.

>Precipitating new conversations with strong implication there’s a better way is less welcome.

Provided you are thick skinned enough not to take offense I don't see the problem.

I've had conversations like this with juniors where they want to rewrite everything and I usually drill in to what they're saying using a kind of socratic questioning method and get them to explain on a deeper level what they think the benefits and costs of the approach they're describing is.

This process is both instructive (juniors are typically pretty bad at cost/benefit analyses, and need to learn) and it makes them feel like they're being listened to. Usually it ends up with an agreement about how to proceed - which is often "good, but not high priority idea but let's put it on the back burner" and is sometimes "bad idea, actually, but that's ok".

IME you get jaded and burned out people much quicker by instinctively rejecting suggestions and telling them to knuckle under, do as they're told and not speak out of turn until they've "earned" the right to do so. That's also a fantastic way of keeping genuinely good ideas and salient observations under wraps.

If you document your architectural decisions and their rationales well, you don't need to repeat the same conversations over and over again. This also helps newcomers to understand why the existing choices were made.

While I understand where you are coming from, you are missing a great opportunity, i.e., getting an outsider look on what you are building.

Thanks for this point of view. I've been on the other end of this situation, where I've come into teams where their architecture truly was problematic. My suggestions were absolutely a provable improvement, but never the less people did not like that I was trying to change things.

I think sometimes folks just aren't a match for a team.

Unless your system is much bigger than 1M LOC I seriously doubt that an experienced good programmer will need more than one year to understand it. It never took me more than one month to understand a system, even when I was junior and when the system was > 1M LOC.

Please do an AMA?

How long did it take to learn those skills? Do you use a tool to understand the code? What is your advice for coming up to speed on a domain you are unfamiliar with?

It’s not really that difficult once you have worked on many, many different systems. When I start a new job (on average less, and sometime much less, than every two years for the joy of all the people here that would never, ever hire me because I change jobs too much) I ask for a complete overview of the architecture in case of server side work and for the gui I just start digging in the code while waiting for the visual Studio installation. Once I have visual studio / Idea I start immediately working on some high priority isolated work while continuing to explore how all the pieces fit together. At this point I realise if there is something that is obscure or that I don’t understand and ask questions. The important thing is probably to first try to understand how it works by yourself and only after some effort ask for clarifications. Normally by the time I finish the first two-three bits of work I already have an idea of some improvement that can be done on a bigger scale to make the coding more productive (it’s easy to find, when you feel pain while implementing something it means that there is space for improvement). At that point usually I start working on the smallest improvement that gives the biggest return in parallel while implementing the next required functionality. At the end everyone wins. The users will have the functionality requested because I implement it, although a bit more slowly compared to working only on that. I have the opportunity to play with the system improving it and I learn something new. In my current job I’m quite lucky because in my role I’m dispatched to different teams that need help to deliver high priority releases. In this way I can work in different systems without changing job.

Reply on news.ycombinator.com