The only thing at all that's wrong about this is the title...
'Onboarding jumpstart' seems like a better title, maybe 'newhire jumpstart' as an alternate.
This is really good advice that can probably actually be generalized, though it doesn't really tell you how to do the actual hard things (like how to take care of that meeting stuff).
(I'll make a different post about my own meetings rant)
Yes this seems to be interesting advice about integrating into any non-trivial project, whether at a new job, at an existing job (e.g. changing team or starting on a client project) or starting to contribute to OSS stuff
The big issue I tend to have with normal corporate meetings is that everyone seems to be a complete cargo cult amateur at it; even when they try.
I think I'd much prefer a "remote first" style of meeting, where everything is designed as an asynchronous, clear deadlines for contribution, process. The actual meetings should be broken up in to focus-groups tackling a specific task, such as brain-storming the definition of a problem, or that problem's solution.
Ultimately there does have to be someone (or some small group) where 'the buck stops'. That's who assigns the other tasks, or at least spawns them and sets default ownership + deadline. (So that the tagged individual can either produce a good alternative, or at least why they're not a good fit.)
I have a different algorithm, which I have successfully used twice: assume the duties of someone one level lower than your designation for at least a month. If you're a tech lead, drop into the shoes of an engineer; if you're a director/VP, drop into the shoes of an architect (provided you're in the technical track). Get down to the weeds. You will not only build a better mental picture of goings-on from first hand experience, the team will more readily accept you as one of their own.
Then you very often won't be doing much (hopefully nothing) that is critical and it's your superiors' and your seniors' job to get you to the point where you can.
I wish this is how all managers thought. Most love to stay on their level, and know nothing of what is actually going on a step below them. They take pride in pushing information up or down the chain without an inkling of how anything actually runs/works.
I forgot to mention how I learned to do this: apparently when Walter Chrysler Jr. joined Chrysler, his father did not put him straight away in an executive position like the other car company founders did. Instead, his first job was to clean out the basement of the Chrysler building. From there, he had to work his way up. It is said Chrysler Jr. became a proper manager as a result. I heard this story while I was a teenager and never forgot it...
From my point of ignorance, the best thing is just start working. Seriously! Get a task and start solving it by your own. Even a simple task in a big project gives you a bigger picture that tons of useless meetings.
This is really great advice. As someone who has recently joined a new team, I can put this to use immediately. Although the advice might differ a bit from an engineer's point of view.
It also taps into a bias that we are more likely to help people in the future if we've helped them already, so asking for help from the start as long as it's appropriate and respectful is win win :)
This advice applies to managers hiring new positions as well, make your new hires do this!
The position in my career where I had the most success started with my manager on my first day pretty much setting this exact exercise as my objective for the first week. He gave me a list of 3 people to talk to and told me to find out who the other people were for myself.
I have applied this approach throughout my career. The recommendation with the greatest long-term utility has turned out to be the last one (the network building) since this provides an organizational map - and knowing where leverage can be applied is powerful knowledge indeed. However the prior two steps suggested are useful for building both rapport and context.
Great advice, but be aware that there are circumstances where it might not work too well:
- disorganized workplaces run by a paranoid manager (all too common): The tactic would probably be conceived as taking too much own initiative, and 'stealing' 30 minutes from an arbitrary number of employees would not go down well (even if it was in your free time). You could try and get managerial sign-off, but don't count on it. If you really need that job in the first place (it's going to be a rough ride) better do over a beer or similar. It is why 'after work' was invented in the first place after all.
- as a very junior or entry-level employee it would seem like overkill in most teams, and probably not work to your advantage. In that case, and if you're ambitious and want to move quickly, try to get the same information but in a less overt way.
as a very junior or entry-level employee it would seem like overkill in most teams
You don't have to start with the senior project manager. Try to find someone who's equally entry-level and been there less than year and talk to them. They'll no doubt be happy to talk and teach you the important things that you actually need to know in your position.
Unless they are jaded from being underpaid or stuck at a position they dislike
Which would definitely be something important worth knowing.
As such it shouldn't matter if they spend their 25 minutes going through the architecture of the build system or ranting about their manager, both will teach you something useful.
This is an incredibly jaded view. Both cases should be encouraging to anyone in a management position. Spending time to understand the lay of the land shows that the new hire is motivated to learn the system they are working on through the other experts on the team. It shows they care, which is a huge win for any project. If a manager truly took issue with this they shouldn’t be managing. It’s also a clear sign to find something else quickly!
Do you think it's normal for software managers to refuse to let their employees schedule 30 minute meetings? That seems absurd to me and would qualify as more dysfunctional than any workplace I've ever been in.
This is knowledge work we're doing here; we're not working the assembly line.
jaded : Bored or lacking enthusiasm, typically after having had too much of something. [0] - hm?
Lacking in enthusiasm, perhaps. There is something to be said for people who venture into every new setting with an optimistic mindset, and not caring if they should tiptoe round, so agree inasmuch.
On the other hand (based on 40 years+ of professional experience), workplaces are in reality on a spectrum regarding these things (not binary good or bad), and peoples seniority as well as their need to take any job in the lower end are on a spectrum as well (some need to take what is provided because of location or other factors). In certain intersections of these factors I'd still say be careful to follow the advice in the linked article very literally.
In the appropriate cases I'd say it was excellent advice though, perhaps that wasn't clear enough.
"made dull, apathetic, or cynical by experience or by having or seeing too much of something" [1]
I would say that someone who feels that it's commonplace for managers to refuse to allow new employees to schedule 30 minutes with other members of their team while on-boarding would fit the definition of being overly cynical.
>disorganized workplaces run by a paranoid manager (all too common)
You basically can't win in a place like this. It's better to keep your head down and leave as soon as you can and try to see the warning signs before taking the job in future.
I read this comment before reading the article (something I often do) and it intrigued me enough to read the actual article. Then I realized that the article is just saying “talk to people when you start a new job”. If that’s an issue for any manager, regardless of my seniority level, I’ll know I’ve made a wrong decision to join that team.
I think the advice in the article was excellent - to the point that your summary quote does it some injustice. But my comment regarded some edge cases, among which the case when a new leader would be compelled to take a job even if workplace was in some disarray. Obviously, if one can pick and choose then it doesn't apply.
Excellent approach! Moreover, this approach helps you quickly build a relationship with each individual person in the team and immediately gain their respect. Everybody likes to be consulted as an expert.
This was also posted internally and somebody else had a better way imho: after every weekly sync, he would take the bullet point list of things everybody in the team worked on/will work on and see if he can explain to an outsider what every item means. If yes, then check that out. Take all the remaining items, grouped by person and have 1:1 with said person to explain you the things you don't understand. Then you can set up a goal, like after 6 months I want to be able to strike out 70% of the items etc.
We had a programmer that tried from the start to impress us. They were constantly suggesting new tools, or changes to the system, or trying to abstract some code.
What they weren't doing was what we asked them to do. They'd put a token effort into that, do it wrong, and then call it done.
On the other hand, all my best newbie programmers came in, buried themselves in their tickets until they understood them, fixed them, and went on to the next ticket. There was very little attempt to change the system in their first year.
I'm much happier with people who focus on doing their job instead of focusing on trying to impress people.
I think implicit in the author's text is the implication that you have a high standard for ownership, so that you can handle your responsibilitites well.
I agree though that this should not be advice for novice programmers, as in this moment of the career you are not sure of the most common pitfalls a team/project gets into and should be mostly concerned about learning the technical knowledge. Trying to do anything else will be a distraction from your current goals.
Very helpful advice for consultants or team members who really care about the project and your career.
But again, as said by a sibling comment, you should always pay attention to disfunctional environments and avoid getting too much attention from sociopathic managers/technical leads. Get some advice from the peers at the same hierarchical level first to know if things are handled smoothly, before iterating.
The best way become more familiar with an unknown team and code base is to work in the code daily. Spending your entire day in 30-minute one-on-ones with people will not help either of those. The exception of course is when you're brought in as a senior-level person in order to change something. But then you need to ask yourself why the senior folks on that team aren't in charge of that.
Spending your entire day in 30-minute one-on-ones with people will not help either of those
I assumed it would be around 5-10 meetings over a few weeks. Half of which can probably be done on lunch breaks. So it shouldn't take too much time away from real work. Obviously you should be working in the code base daily, but in the beginning working 8 hours a day is probably less efficient than working 7.5 hours and spending 30 minutes actually asking someone to explain parts of the code base to you.
> Spending your entire day in 30-minute one-on-ones with people will not help either of those.
How many of these meetings do you think the author is suggesting?? Even one day of that is 16 meetings, roughly the number of people I worked with on a regular basis at Microsoft.
Clearly the author is suggesting to mix them with regular work. One hour of effective meetings per day, plus seven hours in the code, is going to be vastly more effective than just wallowing through code for the entire day.
This confuses me. Coding is more of a tactical operation, and with it you're still going to want a grand strategic vision of what to implement. I think it's foolish to think that you can see the big picture just by trying to make a lot of commits.
The article is clearly targeted at managers and leaders, not your average individual contributor.
Often new leaders & managers start in an established team and want to change something to "make their mark" or have an impact as soon as possible, often with disastrous results (because they don't yet have the context to make informed decisions).
The advice is to spend time with your team to learn the ropes, figure out the internal politics, hear the common pain points and _then_ start addressing things, hopefully with some quick wins (like canceling a wasteful meeting or appropriating a larger conference room) that due to organizational inertia, went unaddressed.
I agree that the OP seemed to miss who the article is targeted at (managers, leaders). However I think this is still very good advice for an IC, even someone straight out of school.
Does it mean they start taking on projects that don't align with their role? Probably not.[0] What it does do is enable them to get a fresh perspective on the org, team and work and perhaps contribute ideas in group settings/meetings/social situations that others may not have considered, by virtue of not having executed the algorithm in the article.
If nothing else it gives one a structured way to gain valuable information about the org and the work, regardless of where you sit in the 'food chain'. It's also a great way to build a network.
[0]Often companies allow for 'stretch' time where ICs can take on side projects. Running this algorithm could be a great way to surface ideas for those kinds of projects.
That isn’t clear to me at all, but then I don’t know the author.
This seems like excellent advice for individual contributors, of whatever seniority, if you can already kick ass at the work you’re assigned, maybe after the first month or two. Provided you have the diplomatic skills to broach process change ideas in a way that doesn’t leave you looking like an entitled asshole, of course. But then, maybe that’s what you meant by “leader”!
You are rather elaborately saying that you want people who do what they're told and don't make waves. Got it--every manager wants that 100 percent. No kidding.
Style tip: When talking about a particular person, don't refer to him or her as "they".
Grammar and style are both ultimately dictated by usage, so if someone insists on plugging in XYZ as a new ultra-PC pronoun I can't really prove that it is incorrect, no matter how ridiculous.
So, that said: The whole point of using "they" is when you don't know the gender of a person and don't want to presume by saying "he" or "she" or muddying up the text by saying "he or she". When you know the gender of a person, using the correct pronoun is better--it's both succinct and corresponds more closely with reality.
It's a touchy subject [I mean, some idiot flagged my comment--come on!] but people tend to over-correct in grammar quite a bit, and over-correcting with "they" happens like this.
How does what you say contradict the OP in any way, shape or form?
He says ask to meet people to understand how everything works. It's not about impressing them, even if it shows proper respect as a side effect (and showing respect by listening is quite the opposing of suggesting new things nilly willy).
The article is about how to make a positive impact as soon as possible, impressing people is only a side effect of that.
It sounds like you're looking for ticket monkeys; the article is about how to become more than that for the people that aspire to that.
The fact that you call your new hires "newbies" and don't expect them to make suggestions for a year is a huge red flag for me. Either you didn't understand that the article is targeted towards experienced professionals switching jobs (first sentence), or you think that a professional will take an entire year to understand your org and be more productive than work on tickets.
Most devs that I know worth their salt are comfortable switching jobs every 2 years or so (whether they choose to or not). The contrast between that and not even being expected to think for a year is massive.
Depends on the size and life of the project and average term of service. If your project is a decade old and massive, where many on the team have been on the project for 5+ years - Yes, a 'newbie' needs a (non-trivial, 1 year could be too long or too short) amount of time to ramp up on why things are like they are before they can make a nuanced suggestion for improvement.
A smaller project that's in a constant state of flux? Of course suggest giant overarching changes when they appear to make sense. What's proper depends heavily on the context of the group and project.
I work on a system that has 15 year old code in it, lots of it in a bad state (it's being removed, but slowly).
I've seen a lot of people come in (category A) who can spout best practices that we're not following, but can't ever wrap their heads around the way the system works, the amount of effort that implementing an idea will take, and the amount of payoff it will offer. They just cargo cult best practices. With those people, I want to say "please just crank out tickets until you understand more".
However, there have also been a small handful of people (category B) who come in, and quickly find ways to make beneficial changes that are achievable and worthwhile. Those people are incredibly valuable.
Concrete advice: if you take a year for any new hire to understand things enough to make changes, you need to work on the understandability of your system, your onboarding, or stop hiring exclusively from category A.
How is “quickly find ways to make beneficial changes that are achievable and worthwhile” distinct from resolving tickets?
That seems like a perfect description of doing a good job at resolving tickets to me. Because if the change was beneficial, it was presumably not just navel gazing architecture astronauting, it was solving an existing problem, right?
General expectation for Senior engineers in the orgs I've been a part of is that they are great problem finders, as well as problem solvers and implementers. If you have a significant backlog of useful improvements that are relatively straightforward to implement, then it's likely better to bring on a few junior engineers to tackle those rather than Seniors. If you're looking to turn the large backlog into a small backlog thanks to innovative solutions or break into new areas, Seniors tend to handle it better.
The red flag in the ramp up curve is really for Senior engineers. If I didn't have a solid understanding and demonstrated ownership of my problem domain within six months along with meaningful projects getting pushed through - my manager would likely be starting an awkward conversation with me.
Part of problem finding is also taking vague inputs "that subsystem is kinda wonky" and transforming it into "that system has these specific problems, which can be fixed with this approach, which will take roughly this long, and help out this much".
The existing group may not have made tickets for something because they think "it'll take six months" or "we'll have to change x,y and z before that idea is gonna help us", because they don't have the time to analyze a known pain point for how painful it is, or even because they haven't thought of the improvement. Then someone realizes that those assumptions are wrong, and finds a big improvement.
If it doesn’t solve a problem the existing team already acknowledged, or at least very directly accelerate the fix for one of those problems, that doesn’t sound like a good outcome from a new hire to me.
I can't decide whether to agree with you or not. On the one hand, I think a lot of the changes I'm talking about changes that should accelerate the fix for problems you have (what team doesn't think "it's too hard to work with x" at some point?).
On the other hand, I feel like you're coming at this from the perspective that your existing team is omniscient, or at least always knows better than someone new. We used to have that dynamic, and I think it's better that we're now more open to new ideas (onboarding is still way slower than I'd like, but it's improved).
Current team certainly isn’t omniscient. Just that you’re liable to make enemies, not friends/develop career, by coming in and proposing brand new, undesired/unforeseen changes and winning the argument with management.
Brand new not-desired-by-team features/changes often end up owned and maintained by the existing team for a long time, often long after you’re gone. You, as a new person, probably aren’t shouldering much maintenance burden yet, bad to be perceived as adding more rather than reducing load.
Much better to fix a generally acknowledged problem, reducing maintenance burden for the existing team.
A sizable fraction of people who have many years of experience aren’t good at making you have fewer problems after 6 months of hard work. Those people still think of themselves as senior, so we have to be careful we’re talking about the same pool of people.
But assuming my high performing senior matches your definition of senior, my experience doesn’t really match your approach with “likely better to bring on a few junior engineers to tackle those rather than Seniors”. The people I think of as high performing seniors will do wonders at making a collection of desired bug fixes and required improvements get done and leave the system with, net, fewer bugs. So it’s never better in my book to assign such problems to juniors.
Some juniors do this, at a lower fix rate. Others introduce as many bugs as they fix. Those either get better fast, or get managed out. So in my world, juniors are a resource (“the future!”) we carefully husband, but try not to have many of them on any given team, because the variance in outcome is so much higher.
> don't expect them to make suggestions for a year
That's not the problem.
The problem is that some newbies want all of the code to be their design pattern of choice; or just want to refactor things until they understand it. Some will just refuse to follow established design patterns and do things like bypass our dependency injector.
For me, it's a red flag whenever someone comes on a team and immediately wants to refactor to use their favorite design patterns, frameworks or style. It's not that their preferred design patterns are better or worse than what we're using; it's that you just don't refactor code on a say-so.
I feel like the article is not about this at all though. If you behaved according to the algorithm as a newbie, you would only refactor and change the design pattern if people told you that that should be done. Which your newbies weren't told according to what you're saying.
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.
> 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".
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 ;)
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.
> 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.
> 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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Why the bias against solving problems that are ticketed? Problems that haven't been discovered yet are seldom more important than the ones that have already been discovered. Unless we're optimizing for your ego, or the existing team truly are idiots whose entire list of known problems deserves to be blown off. (Or more gently, they've made some glaring oversight of a worthwhile value-adding solution.)
Anyway, the article is more about humbly learning how the team works, not about rewriting their codebase just yet, i.e. the opposite of your point about "ticket monkeys."
I don't know about a year, but usually understanding how things work take time. Understanding why they work this way and not another also takes time. If somebody doesn't take time to learn the background of decisions taken, they are liable to repeat the same mistakes and stumble at the same bumps as have been already passed before and encoded in organization's common lore.
There is something called Chesterton fence principle: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence - before proposing to change something, give it an earnest try to figure out why it was like this before, and what changed. Sometimes there's no good reason, or the reason once existing is long gone, and a fresh eye is useful to shake out those cases. In other cases, there are complex and unobvious reasons that cost a significant effort to figure out, and may be not apparent to the fresh eye. So it's better to keep an open and humble mind and at least at first, approach new system with the attitude "please help me learn why it's like this" instead of "this looks wrong, let's throw it away and re-do it from scratch". I'm not sure about a year, but at least a month or two would probably be appropriate. And my experience showed dealing with bugs can actually be very instructive about how things work and why they work this way and not the other.
I am dealing with this at the moment. We have a new contractor and he always wants to make big changes whenever he does something. Sometimes he may be right but I am getting tired explaining that maybe there is a reason why we are doing things a certain way and that the changes he is proposing often are just changes but don't really improve anything.
This is one of the most valuable lessons of contracting: only try to help people who want to be helped. Sometimes you can influence them to want help with something (e.g. an architectural change that will make things better), but if they don't believe there's anything wrong, it's just going to be a pointless battle.
It gets more awkward when you're brought in by one person, but quickly realize that the people you're working with don't want you to do what you were brought in to do. Or when people tangential to the project see it as a threat to the status quo and actively try to prevent you from doing what you're trying to do.
"but if they don't believe there's anything wrong, it's just going to be a pointless battle."
Also consider that the people there aren't dummies but know what they are doing. One of the biggest career improvements I have made is to assume people are competent until I get clear evidence of the opposite. This makes relationships much more pleasant.
That's very true. The middle ground of that is that smart people, making a series of reasonable decisions, can still lead to a terrible destination. I've done it myself, and I've had teams describe multi-year developments where I can't point out a specific place they went wrong. People get caught up in that though, and they're often blind to it until a fresh set of eyes get on it.
[I've spent a lot of time this morning trying to articulate further, and I'm too distracted by the work I'm trying to do. Sorry.]
You're probably correct in your analysis, but in general I'm very wary of people who use self-help readings or techniques to analyze what everyone around them should be doing differently. I often run into people who seem to use these kinds of things as excuses to blame others and not take reasonable action on their own.
I think the original article was written for someone who's going to _manage_ a new team, although it doesn't say that as explicitly as it should. But that's what I'm reading between the lines.
I think the "listening tour" is a pretty good idea even if you aren't a manager. But what to _do_ with it, needs somewhat different advice.
I also suspect the programmer in the comment I'm replying to did _not_ in fact do the "listening tour" that is the main recommendation of the original article. It's not advocating for suggesting changes based on your personal opinion, but only after learning what the team thinks and based on what they think. So the programmer in the comment I'm replying to didn't follow the advice at all.
> We had a programmer that tried from the start to impress us. They were constantly suggesting new tools, or changes to the system, or trying to abstract some code.
If you had people like that, and you weren't able to utilize their talent, then your workplace sucks.
The right way to go when someone says "We should do $X!" and you don't believe it is to say "Prove it!"
Depends on how disruptive their proving it is going to be. If it's not going to be worth the code turmoil, even if they're right, then no, that's not "the right way to go".
Improvements aren't free. They cost, usually more than just the opportunity cost of the implementer's time. There are lots of ideas for improvement that will cost more than they deliver. If I have someone consistently suggesting them, no, I have no place for utilizing their "talent", and no, it's not because my workplace sucks.
And I'd have no use for people merely following commands and doing the minimum work necessary -- like most employees. We cherish ambition and are not afraid to be proven wrong. We prefer to give people the benefit of doubt, rather than assuming ignorance.
I’ve been 100% remote for two years with a trip to the office every 5 months or so and this is roughly the same strategy I use to stay connected during those visits.
“What are you working on? What’s next? What do we need most?" 1-on-1, less than 30 minutes, we're a pretty loosely structured org so it’s all self-initiated. Works well, I’m more comfortable with my colleagues and they’re more comfortable with me, we know roughly what each other are working on, and bandwidth is so much higher in person than on video or text chat.
Could we maybe adjust the title to say something like, “A Career Cold Start Algorithm For Managers”?
It’s somewhat applicable to individual contributors, but it’s intended more for managers, which I didn’t realize until halfway through it. Might just add some clarity for folks opening it up without any context.
You’re not alone in thinking this was advice for managers, many people have said this. But the word manager doesn’t appear in the piece a single time, and I think it’s great advice for individual contributors, so I hope no one editorializes the title this way!
It’s not like only managers can propose slight shifts (desired by the existing team, explicitly in this construction) in process. Unless you’ve got a real jerk of a manager or aren’t doing your base line job well yet, such suggestions, if broached carefully, ought to be welcome.
The higher up you get in engineering the IC/management distinctions normally start to blur. I think this is equally good advice for many senior engineers.
Here's my programmer cold start algorithm for those interested:
1. Go to indeed.com
2. Type in 'software engineer' or 'data scientist' or something like that.
3. Don't put in a city.
4. Put the money slider all the way to the top.
5. Open a few pages of job postings in tabs.
6. Write down every word you don't know.
7. Repeat the process by searching for each one of those words you don't know and then write down additional words you don't know.
Now you have a list of what technologies are valuable in the zeitgeist and your mission is to determine why each technology exists and what it's use case is. You'll then be armed with a larger and more modern toolbox full of tools to reach for when the time comes to solve that kind of problem.
A very effective, but somewhat utilitarian (dare I say, mercenary) approach. It will get you the job, but I don't know how well it will help you keep it (sometimes you might even end up with a mixed bag of buzzwords and hype). I would prefer that candidates try to deeply understand the problems facing the industry and try to develop the skills that solve them.
I know this was half in jest but it speaks to a larger point, that of the "implementation ghetto".
I'm going to get a lot of pushback for saying this, but there are basically three roles in any company: (a) people who do the work, (b) people who make sure the work gets done, and (c) people who decide what work to do.
If you follow the strategy outlined above, you will never rise beyond a pure implementer of someone else's vision.
Empirically, understanding more about the business domain and industry seem to be important if you want to do (b) or (c). If anyone has more tips, I'd love to hear them.
EDIT: When I say "above", I'm talking about in the comment two levels up, not the article.
You missed the step of "understand why each technology exists."
If you understand why a technology exists you are gaining an understanding of problems, and after repeating a few times over a decade you may see patterns in problems that are being solved.
It's easy to mock "AbstractSingletonProxyFactoryBean" but whoever created it was not being wholly onanistic, and if you can't understand why it was created, you are going to be in trouble if you ever create your own framework.
I dunno, this seems almost like what those with vision do. They have a high-level understanding of what's cool and hip and what "should" be used to solve problem other people have had and they think that they can just copy paste it onto their own problem. Then the people who actually have to do the implementation are constantly questioning/regretting, "why was this decision made?"
I'm not sure it's something that can be filtered for, but I don't want to work in an org where technical decisions are made by those who's hands aren't dirty.
thanks this is a great way to learn about new terms. Adding onto this, I usually find the github repo of that keyword term (if its open source) and star it. If its a close source platform, I usually bookmark it on alternativeto.net and check up its competing cases. If its a youtube video, I usually put a like on it. this way I can just thumb through my favorites / likes / stars and get a complete picture of a modern toolset
Another good term is to do "Term VS ______" in google to learn about competing technology use cases as well
At the end of the day some of these terms are possibly all buzzwords but its nice to see what actual companies are using, what that business does, and why they might be using it. Sometimes you get some really nice insights when you dig down deeper (look at their forum posts, etc). This is especially true for things like ecommerce carts (run wappylzer → inspect what the site is running on), sometimes you can actually physically see the decisions they made at a company publically.
I honestly thought about this last night. Current role is a lot of React/Redux/Typescript, which appears to be hot new thing, but is not particularly well paid here in the Southeast. Plus I miss being immersed in dealing with data so I need to lean to a full stack role again
Can't see any such slider. Do I need to get a user ID at the site, or is it just that there is no such thing at indeed.com for Europe? (It only returned jobs near Helsinki [Finland] when I left the City field empty, so I also tried Berlin [Germany], which returned a link to de.indeed.com.)
175 comments
[ 3.0 ms ] story [ 170 ms ] thread'Onboarding jumpstart' seems like a better title, maybe 'newhire jumpstart' as an alternate.
This is really good advice that can probably actually be generalized, though it doesn't really tell you how to do the actual hard things (like how to take care of that meeting stuff).
(I'll make a different post about my own meetings rant)
The big issue I tend to have with normal corporate meetings is that everyone seems to be a complete cargo cult amateur at it; even when they try.
I think I'd much prefer a "remote first" style of meeting, where everything is designed as an asynchronous, clear deadlines for contribution, process. The actual meetings should be broken up in to focus-groups tackling a specific task, such as brain-storming the definition of a problem, or that problem's solution.
This advice applies to managers hiring new positions as well, make your new hires do this!
The position in my career where I had the most success started with my manager on my first day pretty much setting this exact exercise as my objective for the first week. He gave me a list of 3 people to talk to and told me to find out who the other people were for myself.
- disorganized workplaces run by a paranoid manager (all too common): The tactic would probably be conceived as taking too much own initiative, and 'stealing' 30 minutes from an arbitrary number of employees would not go down well (even if it was in your free time). You could try and get managerial sign-off, but don't count on it. If you really need that job in the first place (it's going to be a rough ride) better do over a beer or similar. It is why 'after work' was invented in the first place after all.
- as a very junior or entry-level employee it would seem like overkill in most teams, and probably not work to your advantage. In that case, and if you're ambitious and want to move quickly, try to get the same information but in a less overt way.
You don't have to start with the senior project manager. Try to find someone who's equally entry-level and been there less than year and talk to them. They'll no doubt be happy to talk and teach you the important things that you actually need to know in your position.
Unless they are jaded from being underpaid or stuck at a position they dislike, which is a very common theme in Eastern Europe and middle East.
Which would definitely be something important worth knowing.
As such it shouldn't matter if they spend their 25 minutes going through the architecture of the build system or ranting about their manager, both will teach you something useful.
> things you can easily help with, like “we waste a bunch of time in meetings every week” or “we need a dedicated conference room.”
But agreed, a junior could do the same thing in a less overt way.
This is knowledge work we're doing here; we're not working the assembly line.
Lacking in enthusiasm, perhaps. There is something to be said for people who venture into every new setting with an optimistic mindset, and not caring if they should tiptoe round, so agree inasmuch.
On the other hand (based on 40 years+ of professional experience), workplaces are in reality on a spectrum regarding these things (not binary good or bad), and peoples seniority as well as their need to take any job in the lower end are on a spectrum as well (some need to take what is provided because of location or other factors). In certain intersections of these factors I'd still say be careful to follow the advice in the linked article very literally.
In the appropriate cases I'd say it was excellent advice though, perhaps that wasn't clear enough.
[0] https://en.oxforddictionaries.com/definition/jaded
https://www.merriam-webster.com/dictionary/jaded
"made dull, apathetic, or cynical by experience or by having or seeing too much of something" [1]
I would say that someone who feels that it's commonplace for managers to refuse to allow new employees to schedule 30 minutes with other members of their team while on-boarding would fit the definition of being overly cynical.
[1] https://www.merriam-webster.com/dictionary/jaded
That said, thanks for a better definition of 'jaded' even if not applicable! :-)
You basically can't win in a place like this. It's better to keep your head down and leave as soon as you can and try to see the warning signs before taking the job in future.
I think the advice in the article was excellent - to the point that your summary quote does it some injustice. But my comment regarded some edge cases, among which the case when a new leader would be compelled to take a job even if workplace was in some disarray. Obviously, if one can pick and choose then it doesn't apply.
We had a programmer that tried from the start to impress us. They were constantly suggesting new tools, or changes to the system, or trying to abstract some code.
What they weren't doing was what we asked them to do. They'd put a token effort into that, do it wrong, and then call it done.
On the other hand, all my best newbie programmers came in, buried themselves in their tickets until they understood them, fixed them, and went on to the next ticket. There was very little attempt to change the system in their first year.
I'm much happier with people who focus on doing their job instead of focusing on trying to impress people.
I agree though that this should not be advice for novice programmers, as in this moment of the career you are not sure of the most common pitfalls a team/project gets into and should be mostly concerned about learning the technical knowledge. Trying to do anything else will be a distraction from your current goals.
Very helpful advice for consultants or team members who really care about the project and your career.
But again, as said by a sibling comment, you should always pay attention to disfunctional environments and avoid getting too much attention from sociopathic managers/technical leads. Get some advice from the peers at the same hierarchical level first to know if things are handled smoothly, before iterating.
I assumed it would be around 5-10 meetings over a few weeks. Half of which can probably be done on lunch breaks. So it shouldn't take too much time away from real work. Obviously you should be working in the code base daily, but in the beginning working 8 hours a day is probably less efficient than working 7.5 hours and spending 30 minutes actually asking someone to explain parts of the code base to you.
How many of these meetings do you think the author is suggesting?? Even one day of that is 16 meetings, roughly the number of people I worked with on a regular basis at Microsoft.
Clearly the author is suggesting to mix them with regular work. One hour of effective meetings per day, plus seven hours in the code, is going to be vastly more effective than just wallowing through code for the entire day.
Often new leaders & managers start in an established team and want to change something to "make their mark" or have an impact as soon as possible, often with disastrous results (because they don't yet have the context to make informed decisions).
The advice is to spend time with your team to learn the ropes, figure out the internal politics, hear the common pain points and _then_ start addressing things, hopefully with some quick wins (like canceling a wasteful meeting or appropriating a larger conference room) that due to organizational inertia, went unaddressed.
When I come to a new team, I always try to find out a lot of things during the coffee breaks. But the approach from the article is more structured.
So, I guess I will try a mix of the two approaches next time ;)
Does it mean they start taking on projects that don't align with their role? Probably not.[0] What it does do is enable them to get a fresh perspective on the org, team and work and perhaps contribute ideas in group settings/meetings/social situations that others may not have considered, by virtue of not having executed the algorithm in the article.
If nothing else it gives one a structured way to gain valuable information about the org and the work, regardless of where you sit in the 'food chain'. It's also a great way to build a network.
[0]Often companies allow for 'stretch' time where ICs can take on side projects. Running this algorithm could be a great way to surface ideas for those kinds of projects.
This seems like excellent advice for individual contributors, of whatever seniority, if you can already kick ass at the work you’re assigned, maybe after the first month or two. Provided you have the diplomatic skills to broach process change ideas in a way that doesn’t leave you looking like an entitled asshole, of course. But then, maybe that’s what you meant by “leader”!
Style tip: When talking about a particular person, don't refer to him or her as "they".
Can you explain why, please?
So, that said: The whole point of using "they" is when you don't know the gender of a person and don't want to presume by saying "he" or "she" or muddying up the text by saying "he or she". When you know the gender of a person, using the correct pronoun is better--it's both succinct and corresponds more closely with reality.
It's a touchy subject [I mean, some idiot flagged my comment--come on!] but people tend to over-correct in grammar quite a bit, and over-correcting with "they" happens like this.
Perhaps the parent was trying to conceal the identity of the person in question and gender would be too much of a giveaway.
He says ask to meet people to understand how everything works. It's not about impressing them, even if it shows proper respect as a side effect (and showing respect by listening is quite the opposing of suggesting new things nilly willy).
It sounds like you're looking for ticket monkeys; the article is about how to become more than that for the people that aspire to that.
The fact that you call your new hires "newbies" and don't expect them to make suggestions for a year is a huge red flag for me. Either you didn't understand that the article is targeted towards experienced professionals switching jobs (first sentence), or you think that a professional will take an entire year to understand your org and be more productive than work on tickets.
Most devs that I know worth their salt are comfortable switching jobs every 2 years or so (whether they choose to or not). The contrast between that and not even being expected to think for a year is massive.
A smaller project that's in a constant state of flux? Of course suggest giant overarching changes when they appear to make sense. What's proper depends heavily on the context of the group and project.
I've seen a lot of people come in (category A) who can spout best practices that we're not following, but can't ever wrap their heads around the way the system works, the amount of effort that implementing an idea will take, and the amount of payoff it will offer. They just cargo cult best practices. With those people, I want to say "please just crank out tickets until you understand more".
However, there have also been a small handful of people (category B) who come in, and quickly find ways to make beneficial changes that are achievable and worthwhile. Those people are incredibly valuable.
Concrete advice: if you take a year for any new hire to understand things enough to make changes, you need to work on the understandability of your system, your onboarding, or stop hiring exclusively from category A.
That seems like a perfect description of doing a good job at resolving tickets to me. Because if the change was beneficial, it was presumably not just navel gazing architecture astronauting, it was solving an existing problem, right?
The red flag in the ramp up curve is really for Senior engineers. If I didn't have a solid understanding and demonstrated ownership of my problem domain within six months along with meaningful projects getting pushed through - my manager would likely be starting an awkward conversation with me.
Part of problem finding is also taking vague inputs "that subsystem is kinda wonky" and transforming it into "that system has these specific problems, which can be fixed with this approach, which will take roughly this long, and help out this much".
The existing group may not have made tickets for something because they think "it'll take six months" or "we'll have to change x,y and z before that idea is gonna help us", because they don't have the time to analyze a known pain point for how painful it is, or even because they haven't thought of the improvement. Then someone realizes that those assumptions are wrong, and finds a big improvement.
On the other hand, I feel like you're coming at this from the perspective that your existing team is omniscient, or at least always knows better than someone new. We used to have that dynamic, and I think it's better that we're now more open to new ideas (onboarding is still way slower than I'd like, but it's improved).
Brand new not-desired-by-team features/changes often end up owned and maintained by the existing team for a long time, often long after you’re gone. You, as a new person, probably aren’t shouldering much maintenance burden yet, bad to be perceived as adding more rather than reducing load.
Much better to fix a generally acknowledged problem, reducing maintenance burden for the existing team.
But assuming my high performing senior matches your definition of senior, my experience doesn’t really match your approach with “likely better to bring on a few junior engineers to tackle those rather than Seniors”. The people I think of as high performing seniors will do wonders at making a collection of desired bug fixes and required improvements get done and leave the system with, net, fewer bugs. So it’s never better in my book to assign such problems to juniors.
Some juniors do this, at a lower fix rate. Others introduce as many bugs as they fix. Those either get better fast, or get managed out. So in my world, juniors are a resource (“the future!”) we carefully husband, but try not to have many of them on any given team, because the variance in outcome is so much higher.
That's not the problem.
The problem is that some newbies want all of the code to be their design pattern of choice; or just want to refactor things until they understand it. Some will just refuse to follow established design patterns and do things like bypass our dependency injector.
For me, it's a red flag whenever someone comes on a team and immediately wants to refactor to use their favorite design patterns, frameworks or style. It's not that their preferred design patterns are better or worse than what we're using; it's that you just don't refactor code on a say-so.
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.
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".
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.
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 ;)
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.
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.
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.
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 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.
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 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'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.
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.
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.
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.
I think sometimes folks just aren't a match for a team.
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.
2 years? Most of the companies and projects I joined were long gone and dead 2 years down the road. Different industries indeed.
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.
Why would it take you 2 years to understand it about someone? In my experience, real figure is closer to something about 2 weeks.
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.
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.
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?
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 longer, I changed that to "regardless of the org structure, the org chart doesn't fully capture who has influence and who doesn't."
refers to the 1972 essay The Tyranny of Structurelessness by Jo Freeman. http://www.jofreeman.com/joreen/tyranny.htm
Nothing new under the sun.
Anyway, the article is more about humbly learning how the team works, not about rewriting their codebase just yet, i.e. the opposite of your point about "ticket monkeys."
There is something called Chesterton fence principle: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence - before proposing to change something, give it an earnest try to figure out why it was like this before, and what changed. Sometimes there's no good reason, or the reason once existing is long gone, and a fresh eye is useful to shake out those cases. In other cases, there are complex and unobvious reasons that cost a significant effort to figure out, and may be not apparent to the fresh eye. So it's better to keep an open and humble mind and at least at first, approach new system with the attitude "please help me learn why it's like this" instead of "this looks wrong, let's throw it away and re-do it from scratch". I'm not sure about a year, but at least a month or two would probably be appropriate. And my experience showed dealing with bugs can actually be very instructive about how things work and why they work this way and not the other.
To quote the seven habits of effective people:
"Seek first to understand, then to be understood"
It gets more awkward when you're brought in by one person, but quickly realize that the people you're working with don't want you to do what you were brought in to do. Or when people tangential to the project see it as a threat to the status quo and actively try to prevent you from doing what you're trying to do.
Also consider that the people there aren't dummies but know what they are doing. One of the biggest career improvements I have made is to assume people are competent until I get clear evidence of the opposite. This makes relationships much more pleasant.
[I've spent a lot of time this morning trying to articulate further, and I'm too distracted by the work I'm trying to do. Sorry.]
I think the "listening tour" is a pretty good idea even if you aren't a manager. But what to _do_ with it, needs somewhat different advice.
I also suspect the programmer in the comment I'm replying to did _not_ in fact do the "listening tour" that is the main recommendation of the original article. It's not advocating for suggesting changes based on your personal opinion, but only after learning what the team thinks and based on what they think. So the programmer in the comment I'm replying to didn't follow the advice at all.
> We had a programmer that tried from the start to impress us. They were constantly suggesting new tools, or changes to the system, or trying to abstract some code.
If you had people like that, and you weren't able to utilize their talent, then your workplace sucks.
The right way to go when someone says "We should do $X!" and you don't believe it is to say "Prove it!"
Improvements aren't free. They cost, usually more than just the opportunity cost of the implementer's time. There are lots of ideas for improvement that will cost more than they deliver. If I have someone consistently suggesting them, no, I have no place for utilizing their "talent", and no, it's not because my workplace sucks.
I'm not sure I would call that "talent", and based on that performance, I certainly wouldn't want their "improvements" on our systems.
“What are you working on? What’s next? What do we need most?" 1-on-1, less than 30 minutes, we're a pretty loosely structured org so it’s all self-initiated. Works well, I’m more comfortable with my colleagues and they’re more comfortable with me, we know roughly what each other are working on, and bandwidth is so much higher in person than on video or text chat.
It’s somewhat applicable to individual contributors, but it’s intended more for managers, which I didn’t realize until halfway through it. Might just add some clarity for folks opening it up without any context.
It’s not like only managers can propose slight shifts (desired by the existing team, explicitly in this construction) in process. Unless you’ve got a real jerk of a manager or aren’t doing your base line job well yet, such suggestions, if broached carefully, ought to be welcome.
"...the natural instinct to push for early impact leads many incoming leaders into challenging relationships..."
1. Go to indeed.com
2. Type in 'software engineer' or 'data scientist' or something like that.
3. Don't put in a city.
4. Put the money slider all the way to the top.
5. Open a few pages of job postings in tabs.
6. Write down every word you don't know.
7. Repeat the process by searching for each one of those words you don't know and then write down additional words you don't know.
Now you have a list of what technologies are valuable in the zeitgeist and your mission is to determine why each technology exists and what it's use case is. You'll then be armed with a larger and more modern toolbox full of tools to reach for when the time comes to solve that kind of problem.
Rinse, repeat every few years.
Hope that helps someone. :)
ghotli did address that, obliquely.
I'm going to get a lot of pushback for saying this, but there are basically three roles in any company: (a) people who do the work, (b) people who make sure the work gets done, and (c) people who decide what work to do.
If you follow the strategy outlined above, you will never rise beyond a pure implementer of someone else's vision.
Empirically, understanding more about the business domain and industry seem to be important if you want to do (b) or (c). If anyone has more tips, I'd love to hear them.
EDIT: When I say "above", I'm talking about in the comment two levels up, not the article.
If you understand why a technology exists you are gaining an understanding of problems, and after repeating a few times over a decade you may see patterns in problems that are being solved.
It's easy to mock "AbstractSingletonProxyFactoryBean" but whoever created it was not being wholly onanistic, and if you can't understand why it was created, you are going to be in trouble if you ever create your own framework.
I'm not sure it's something that can be filtered for, but I don't want to work in an org where technical decisions are made by those who's hands aren't dirty.
Another good term is to do "Term VS ______" in google to learn about competing technology use cases as well
At the end of the day some of these terms are possibly all buzzwords but its nice to see what actual companies are using, what that business does, and why they might be using it. Sometimes you get some really nice insights when you dig down deeper (look at their forum posts, etc). This is especially true for things like ecommerce carts (run wappylzer → inspect what the site is running on), sometimes you can actually physically see the decisions they made at a company publically.
I dont see a slider on indeed. What are you talking about?
How helpful would this be for someone self taught looking for a job?
Can't see any such slider. Do I need to get a user ID at the site, or is it just that there is no such thing at indeed.com for Europe? (It only returned jobs near Helsinki [Finland] when I left the City field empty, so I also tried Berlin [Germany], which returned a link to de.indeed.com.)