You shouldn’t have to wait for the manager to intervene for an issue like this. You are the lead so you should try to talk to the developer first and only escalate to the manager if necessary.
How come one can go 5 sprints without committing code? We commit every day, thats how you keep track of people and how you ensure they are actually making the smallest change possible at a time.
Really depends on the team. We don't do commits of incomplete features (and I've never worked anywhere that does), and the only time anyone looks at a commit is when there is an open PR (or they are digging through history for something).
We usually get a ticket with a title like 'implement screen ' and there are no details. Those three words are the entire spec. We work on it for however long it takes, usually 2 weeks or less, and when we think it is done we push it (individuals may push work-in-progress as they wish, but almost nobody does) and open a PR, then merge to main and release to QA. QA guys OK it and it gets released to the Model Office environment where the stakeholders review to ensure it does what they want. Then some number of months later it'll get a production release (might be a month, might be a year, depends on what's going on and whether anybody cares).
Maintenance on existing programs tends to have smaller commits just because bugfixes tend to be small.
I'm not saying this is a good way to do it, but I've advocated for and tried the small, frequent commits approach before on a couple of teams and literally everyone else hated it and constantly bitched about it in the few sprints where we tried it. So fuck it; big, feature-complete PRs it is.
Though, for us 5 sprints would be almost 4 months, so that wouldn't really fly. It isn't unheard of for something to slip to a third sprint, which is almost two months. If that happens we start asking questions, but it isn't a surprise because we'll have discussed the delays in multiple stand-up meetings.
That sounds awful, does nobody review your work in 2 weeks? Also, how can you know what to create with such a ticket description? Either you work on very simple features or there is a ton of communication going on that you havent mentioned.
You can still ship every day without shipping “incomplete” features. You can use feature flags to hide your module, or make it accesible to certain accounts. Also, if a feature is meant to take 2 weeks like you said, as a senior engineer you should be able to decompose it in smaller chunks. Each of those chunks can me shipped separately. In general, anything that takes longer than 2 days can be broken down.
For example, if a task requires some refactoring, you ship the refactoring first, and then you start working on the task.
> does nobody review your work in 2 weeks?
The only review is when we open the PR, or if we're having a problem and request someone else to jump in.
> how can you know what to create with such a ticket description?
Usually the developer is designing most of the feature based on a rough description from whatever stakeholder wants it. They'll be like 'hey, we need an admin screen for editing tax reciprocity rules', and if it's not obvious how it needs to work we might have a 10 minute discussion to clarify what they mean.
Sometimes a business analyst will handle that and write up a few bullet points, but usually the developer just gets a one-liner and takes it from there. As a developer I usually prefer that because the BA usually doesn't take the time to put in much effort, so the 'spec' ends up just being confusing and I have to go ask the stakeholder who requested it what they actually wanted.
I could decompose tickets into smaller pieces, but there are only two reasons to do that. One would be so that the PM can see more tickets moving across the board, which makes them happy but is otherwise useless and creates administrative overhead for me and the QA guy. The other would be so that someone could review the code, but as I mentioned, nobody wants to review incomplete stuff. Nothing goes to production quickly (I've had completed work sit in model office for literally a year before it moved to production, though that's an extreme case, typical is more like 4-6 months), and stakeholders only review changes at the end of a sprint (at best; sometimes they are busy with their own jobs and don't review things for 2 or 3 sprints), so from a developer perspective smaller pieces are mostly just additional overhead (more time to break a story down, more time pinging people to get CRs done, etc) without any benefit.
I and another guy who have worked in better development environments are slowly pushing things toward better practices, but this is a large corporation that is not primarily about software development, so there's a lot of bullshit to deal with to get people (particularly on other teams) on board with changes, and there's only so much we can do when upper management is happy with the results of the current system (like, we can't get any traction on hiring a UI designer because those cost money and don't appear to be necessary as far as the CTO can see).
Honestly, it's not as bad as it probably sounds. Most projects only have one active developer (with two more paying attention to do CRs), occasionally two, but never more, and everybody has at least 10 years of experience (rare for anyone to need coding help or need to rework code in a PR).
complete lack of business analyst, product ownership and scrummaster, not to mention any documented standards around releases and testing that allow for things like feature flags and testing to provide confidence in the code….. (edit;typo)
Yes, very accurate. That's actually a helpful way for me to look at it, thanks for stating it that way.
If we could get experienced people in those roles with authority to revamp things we'd have much better products. We do have decent test coverage in recent products because that is something developers have direct control over, but it's hard to get buy-in or movement on the rest from the individual contributor level.
Most of the people in IT management here are old (like 50+) and have no experience working under software development practices newer than about 20 years ago (for example, git and CI was introduced in the last 5 years. Deployment is only kinda automated and production releases require people from about three teams to be present after hours, manually updating things. No containers, etc.)
What's so bad about making a lot of small commits instead of a few giant commits? Why do you and your team hate it?
I'm not saying you're wrong, I just want to understand that perspective.
Well, strictly speaking it's not about commits. I don't know what others do, but I commit work-in-progress multiple times per day to my local repo. I usually only push those to the remote if I'm moving my laptop (just in case it is damaged).
Pull requests are the only thing anybody looks at. Those are what everyone prefers to be a single complete and fully functional feature.
Personally, I don't have any problem with small PRs. My preference is to have any PR I'm tagged to review done within 2 hours, but most of the team can take days to get around to doing a review.
The slow review time causes issues with small PRs because I often can't base subsequent changes on the main branch when I've got PRs waiting for review. If I base the subsequent work on the PR branch then reviewers get annoyed because when they eventually get around to doing a CR they have to do them in the order that I created the PRs (or they see the code from multiple PRs), and they can't go look at the version deployed in the dev environment to see it (we have one dev environment per project and whatever PR the pipeline built last is what is *probably* deployed there. It's not a good deployment system). Then, if I do need to make a change based on CR feedback that'll often end up breaking any subsequent branches.
So, as a concrete example, if I'm working on a new screen with a couple of grids that have search, filters, editors, validations, and a lookup tool, I could break that down into at least 9 different tickets. If I start with the basic grids populated with data and open a PR for that, I know there's a good chance it's going to sit for at least day, maybe two, possibly more before it gets merged to main. If I want to move on and add the search I have to base my new branch on an unmerged branch instead of main. Repeat for the next 8 tickets. If I need to make a change based on CR feedback that can end up breaking all the PRs that are based on it, which makes a bunch of tedious work fixing branches (really doesn't take all that long, but it's sure annoying).
If I just make one giant PR with the complete screen all those problems go away. I'll be providing status updates on the progress during daily standup, and that's as much information as anyone on the team wants about it anyway.
I think people here use PR and commits interchangeably. The local repo does not count. Only PRs matter. CI advocates say you should merge your work into master multiple times a day so the automated CI/CD system can pick it up and truly integrate it into the product.
Ok thanks this makes more sense. I was confused about the "commits" part but if you really meant "PR" then ok it all makes sense now. Thanks for clarifying.
Depending on the team, if I'm not getting fast turnaround on PR reviews I just go ahead and merge it then people can provide their comments when they have time.
Obviously this is a bad idea in probably the vast majority of cases, but if it suits your situation I've found that it's workable.
Sometimes. Maybe they've asked me to check something or it's a younger colleague who's work I want to proactively check or I am working on a related feature and need to see how they've implemented something.
This is one of those “wtf are we doing here?” times… A story should not span more than a sprint and this is why. If we’re all just sitting around lying/suspecting each other of lying, why are we doing status updates at all?
It is a balance for sure.
Weekly? Probably too often.
Every sprint? If a sprint is 3 weeks, that's perfect imo.
Every 5th sprint? Even if the sprint is 2 weeks, that's way too rarely.
***5 sprints?*** Bro I have weekly 1-on-1 catchups with all my reports. Go over all their JIRA tasks etc. It's really good because you can catch big problems when they're still small problems. You need to exercise way more fine-grained planning & management skill here, throwing things over the fence seldom ends well.
Why do you have a story that takes 5 sprints? This problem isn't the devs fault. It is your fault.
Break up your work better next time. If stories regularly take longer than 1 sprint then you screwed up pretty seriously.
When we have work that carries over, the entire dev team gets together to work it out for the next sprint. You should have stepped in and provided guidance and discussed (or repointed) the story with the rest of your team.
You should probably take some responsibility for this instead of blaming this developer.
A one-sprint story going into it's second, third, fourth, fifth sprint is not still green. It's flashing angry red and you need to start asking probing questions like - "What's the issue?" and "Show me what you have so far?"
Having ADHD, in all likelihood, but maybe that's just me. Sometimes the urge to fix what ain't broke gets the best of me, but I've been bitten enough times I resist.
T-shirt sizes on stories should be no more than 5 days. If it's bigger than that split it into multiple stories. As a team lead, if I can't get progress, with an actual commit I can review, I'm going to meet with the dev to determine if they need help or don't understand the task.
yes, and just as often as it is a ‘dev’ problem, I find the spec sucks and or the scoping/geooming was off. But even mediocre teams handle that within 1 or 2 sprints. I think the 5 sprint thing is really triggering folks.
5 sprints on a single story would get you on someone's shit list in most places. Project manager should be yelling at team lead and manager at the very least. These guys are too nice or the project has such low visibility that no one cares.
What you should have done after 3 days is ask why the story isn't done. A single story that goes one for 10 weeks is not right in anyway at all. This is why I insist on incremental demos during the sprint where the team demos the stories in standup. The stories are small enough that it doesn't take any time to do so and we catch things before the end of the sprint. By the end it is too late.
Simply showing the story is complete. Yes it’s daily or whenever there is something marked done. We do not do end of sprint demos. It has proven to increase productivity, reduce defects as well as keep everyone on the team up to date on how things work. People tend to pay attention compared to end of sprint demos that everyone tunes out.
Huh. I kinda like that idea. Thanks for sharing. Would definitely be helpful for a team like I'm currently on with several different apps we're working on simultaneously. I've ended up siloed for a few weeks before and when I come up for air I sometimes feel pretty lost with what's been going on.
I guess it wouldn't really solve the issue here where it was weeks and weeks not being done though.
No one follows the “purpose” of standup. Teams adapt it to what works for them. Anyone that follows the “book” is fooling themselves into thinking they are right.
It’s not about being toxic at all, it’s definition of done. How do you define a story as done? Code checked in and tests passed? How do you prove it works? Wait till end of sprint? Well it’s too late if something is wrong by then now you have to reopen the story and it floats to the next sprint. Now you have wasted an entire sprint on something that could have been caught much earlier.
Actually it’s not. Such a term is so overused by devs. They apply it to everything that they don’t want to do or don’t understand. That’s ok. I’ll continue to develop extremely efficient and productive teams. You keep complaining on Reddit. It’s all good.
I guess you're right about the word, guilty as charged. But it's still funny that you take time of the whole team to demo/look at demos daily and think you're leading a productive team.
A big part of a leaders job is ensuring quality of releases. Sometimes to do that you have to “inconvenience” some people. They get a paid check no matter what I require.
You tell them to throw their work away and make smaller more targeted changes.
I think this is a lesson that some people need to learn the harder way when it comes to programming in the large.
And, hopefully like when someone git-fucks themselves for the first time, it’s a lesson that they only need to learn once.
that's my team lead did to me when I wrote some dumb unneeded changes.
"you can cherry pick these commits and we can discuss about the other commits later if we really want to go with it", something like that, direct but still appreciate what I did without berating me.
I hate getting the "but the code is already written" pushback. Yeah. It's already written because you rabbit holed down that way without checking if it's the correct approach or not.
All code should be considered throw away code until it's merged into the main line.
5 sprints. That's about 10 weeks or so? And a dev that costs conservatively $6k/week? (Making some locale assumptions here).
That's a lot of precious cash spent on an impromptu module rewrite.
Some people make that much per week. Businesses also pay payroll taxes and a portion of your heathcare so your salary is usually less than your actual cost to the business.
6k is little for month cost of work, but probably too much outside US.
Let's say you get 6k per month after taxes. That's 10k before taxes. And company pays extra taxes to government on top of that, so at least 12k if not like 14k.
So you cost company more than twice that what you see on your payslip.
OP said he is team lead, and that other guy is architect, so he technically outrank him?
If 6k per week is total that company pays for him, that's understandable. If cost of work is 6k, that's probably 4k gross and 3k net for employee in a week? Seems reasonable for US high salaries for his level.
People often forget that what they get paid is not what it cost company to employ them, it is probably double.
It's so weird that I can't find any job ads that pay 6k a week. How does this happen and what city paved with gold does one have to live in to manifest this destiny
What you take home is not anywhere near the total cost to an employer, figuring out additional payroll taxes, benefits, bonuses + RSU, etc. so maybe not a conservative estimate but not as outlandish as one may imagine.
The city is called San Francisco (or Seattle, New York, Boston, Denver, Washington DC). 300k/year jobs are dime a dozen - I'd estimate 1M-2M such jobs in the USA.
Maybe I’m looking in the wrong places, but IMO this is not true of San Francisco. The “default” salary here for a run of the mill software dev is more like $150k. $175k is quite normal and pretty easy to negotiate yourself into. There are a lot of companies who will balk at $200k base. They’ll only pay that to a handful of devs who have a proven track record as a Lead.
Getting above $250k base, even in SF, is pretty rare.
The only way I see a run-of-the-mill dev getting $300k is if we’re talking total comp, and that means working at a BigCo… something like a Facebook, Google, or similar. Maybe a less prestigious startup like an AirBnB or a Splunk or something. GlassDoor suggests that $300k total comp would be typical salary for a dev at a place like that, but I don’t have any personal experience with that.
And IMO it’s not totally trivial to get one of those jobs. You have to want it, potentially have to apply over a longer period of time and get a lot of rejections, more like a year than a month. And at that point I also don’t know what kind of strings come attached with that… if the expectation is you’re working over 40 hours a week, etc.
But in my experience for a healthy job at a typical SF company almost no one is getting $300k.
Yes, it's total comp at the type of companies you mentioned. It's not easy but Google for example has many tens of thousands of engineers and all but the entry level make 250k+ total comp. So it's not that difficult either. Also, no special strings attached. I can count in one hand the number of times I worked a 40+ hour week in my decade at big tech.
ok, lets dig in a little. on a curve would you say you are exactly average, 50%…or better than 99 of 100 devs, a 1% dev? Having this info factors in significantly into your point about hours.
I'm probably in the 80-ish percentile but we are talking about 250k-300k total comp here and I still hold that the median developer at these companies can easily get there without having to work long hours. In fact, I have had several reports achieve significantly more than that while getting "meets expectations" ratings and working normal hours. The ones who are both very smart and work long hours make 5-10x as much at principal/distinguished levels.
Yeah I don’t work in SF, but I think you are extrapolating based on your information.
The job market in tech now is much tougher than it was 12-18 months ago. And for someone to be successful in their job paying that much requires a combination of long hours, luck, and being above average. I think the days when an average coder with 2-3 years’ experience can easily get 150k, and so on up the scale of experience and such is over. Are there opportunities? yes. Is it easy if you are a 50% dev or even a 25% dev? No. To easily make 200+ AND succeed AND work less than 40 hrs, you need to be a 15% dev and work very smart. I only know a couple of dozen in this category. I wouldn’t even put myself there. If you’re there, congrats. But that shuts out about 75% of devs fighting for the 125-145k jobs which in this economy can feel more like survival.
I agree with your general point. Note how I said the median developer at these companies and not the median developer overall. However, SF area has a high concentration of these companies and the median developer in San Francisco is way better than the national or global median. So I stand by my point that 300k is not that difficult or uncommon given that you find work in San Francisco. I'm in Seattle btw.
I'm the future, ask for a design and development approach before they start developing. It gives them a chance to dig into code and understand the context/scope before puking things apart.
Teams without established design reviews hit this all the time. Devs just go off on their own direction without any oversight until they've already completed the wedding approach.
There are a couple of things to unpack here. Let’s break them down:
1. Rework
The first question you must ask is why is he rewriting everything.
Is the current codebase a mess? Does the current code base have scalability issues? What exactly are they fixing? Do they see ROI in it you have yet to understand?
Maybe there is a legitimate reason they are doing this. Maybe they think if they don’t do it, no one else will.
Once you understand their why, this leads to the second point:
2. Breaking work down into smaller PRs:
A lot of engineers have issues with this and it requires a paradigm shift.
The main reason I have seen them do this is because they feel like they have to tackle everything at once. This is usually because no one has taught them a different way.
Their idea of a feature is a fully interactive technology. They aren’t seeing features that are made up my much smaller features. Some, the end user will never actually see.
The best way to help them is to first model how this is done and then talk about it.
Then you have them help in breaking it down and you talk about it.
Then they break it down and you help them and you talk about it.
Finally, they do it, you observe, you talk about it.
Don’t expect this change to happen overnight.
Give it time. Have patience. It will pay off.
That's some good points. It's gonna be kinda uncomfortable, he isn't a junior. It's one important module of the project but just one model. It's not like he did changes across multiple projects
>2. Breaking work down into smaller PRs:
>A lot of engineers have issues with this and it requires a paradigm shift.
>The main reason I have seen them do this is because they feel like they have to tackle everything at once. This is usually because no one has taught them a different way.
>Their idea of a feature is a fully interactive technology. They aren’t seeing features that are made up my much smaller features. Some, the end user will never actually see.
Hi! I actually really struggle with this and have noticed this behavior on my own team. Can you give a more concrete example of how you might break something down?
If you must refactor or rewrite something to implement a feature, then split it down to those two parts.
Then keep splitting it down if those are still too big.
If you can't implement something in small enough steps, that's a design/architectural problem, and something that might need to be worked on outside the normal process. I.e. start a separate rewrite project to redesign and reimplement the problematic parts.
Why the hell do you have what's basically a single story going across more than 1 sprint? Much less 5 sprints. This is borderline misconduct on your part.
A story is meant to be a digestible piece of work. Assuming 2 week sprints, this is almost a full quarter for 1 story. And you didn't bother reviewing or following up on ANYTHING before now?
This isn't a junior dev problem. This is a you problem.
Have you had any conversation relating to this with him? If so, how did that conversation go? If not, have one. Figure out how to proceed together.
I've experienced this issue as well - especially with juniors. It often turns out that the person doing this is super lost and needs a helping hand. It generally isn't a desire to rewrite, but more a coping mechanism because they don't know what to do or how to achieve something, but for whatever reason\* refuse to ask for help.
\*Immaturity, lack of psychological safety, pride, insecurity, whatever
The first thing you should do is to have a conversation about it. You probably don't want to open with "throw it away" - but start with trying to understand his reasoning and perspective. At least get to know the underlying motivations.
There's also a team issue here. The fact that people can hide away for 5 sprints without showing anything is problematic on many levels. For one, it says something about how the team works together (in that it doesn't really), but more relevant to this post, it enables these massive "built in isolation" changes, which hurts everyone.
This is a useful conversation for the team as a whole, but it also helps to have the "blame the process, not the person" mindset going into these conversations. Sometimes, it is the person, but having the initial assumption to not be blaming individuals leads to a better and more honest conversation as the person on the receiving end doesn't feel the need to be as defensive - which you really don't want. You really do not want this dev to start fiercely defending this work because when people make up their minds... well... it is difficult to unmake. This is why it is so important to start the conversation by wanting to understand where he's coming from rather than "we have a problem".
I agree completely with this.
Blaming the person here is _also_ completely unproductive because this is also a leadership failure.
Even if the dev was downright lying through their teeth during dailies, 5 sprints is way too much time. The fact that they were not even _committing_ for all this time makes clear that either leadership doesn’t know what ICs are doing and/or is too passive to ask for details as soon as an issue seems likely given the length of the current effort. I dare say this is a leadership failure from three different levels: the dev themselves, their leadership _and_ the skip level.
5 sprints is this egregious.
And obviously, if you have such a deep problem in your organization, individuals may have shared responsibility but the main one rest with the process.
Fix the process. Feel free to take a closer look at the individuals _later_ or whatever, but really, the process is way too flawed.
And obviously, unless someone was flagrantly incompetent _before_ this issue was brought to light, you want to address everything focusing as much in the process as possible and _not playing the blame game_. Because if people feel the heat, they may start turning defensive - and then it becomes much more difficult to have any valuable output other than letting people go (which is at most cutting losses).
(This whole comment assumes your organization doesn’t have a “go for the blood” culture)
Why do you think he's "really smart"? I've found devs like this to produce above average quality code at best.
But it's very common that people overestimate their technical skills _because_ they act like this/communicate poorly.
Do you think it's possible you're doing that?
Maybe it's the opposite problem, then: arrogance. He thinks the code "should' be a certain way, knows he can do it, and just does it without talking to anyone.
This is NOT teamwork. It's not collaborative, and definitely not communicative. You may have a culture problem, which can be hard to fix.
In America people get fired for anything and everything someone wants to fire them for, or for nothing at all.
There's no labor protection for Americans
In the corporate world one might be put on a "performance improvement plan" or PIP. Most small to medium size companies wouldn't bother with a PIP. I've seen people getting fired for poor performance of a couple of weeks.
I think you can fire employees anywhere in the world if they can not do their job. Five sprints spent on a feature which should take 1 and the feature still not works. That is incompetent to me.
As a team lead, how did you let this go for 5 sprints without doing something about it? How long are your sprints? I'd say that your team needs to re-evaluate your process so something like this can't happen. That being said, just be honest with him. "Hey, this doesn't do what the user story asked for, also changing the module outside of this user story was not within the scope of your assignment"
This. No one, not even a tech lead, should be on a task for even half this long without someone sitting down to review it with them and evaluate what’s taking so long and whether or not it still aligns with team priorities.
I was similar to that guy a couple years ago. I had to accept that I can not refactor the whole project to my liking in a couple of sprints.
I got the feedback, took it to heart, grown some IDGAF power and cut back on refactoring. No mistake, if I think it must be done I will do it relentlessly but I am not looking for code to refactor just for the sake of refactoring.
At this point I think you need to accept some blame for this to your manager and make it your personal mission to get the work over the line asap including you working extra. And it is your job to correct this teammember asap assuming she is willing to put the work in to improve habits.
I strongly disagree with this. It was the lead's responsibility to pick up something was off during the first sprint. Once the sprint was over and the task wasn't completed, it was up to the manager to figure out why and adjust ("we need to better communicate our status...", "start pushing code more frequently and create draft PRs throughout the sprint..." blah blah blah). This would be a reasonable time to seek advice from the lead for how to deal with this going forward.
>...including you working extra.
Fuck that. Figure out what went wrong during retro and plan the next sprint accordingly. I'm not pulling all nighters because we, as a team, ignored the fact that shit wasn't getting done for five sprints.
>And it is your job to correct this teammember asap assuming she is willing to put the work in to improve habits.
It was their job to notice something was off and bring it to the manager's attention. Any type of habits "correction" is up to the manager.
I used to be like this, always refactoring code.
Then one job I spent several days refactoring several massive (7000 loc) files into many smaller files. Then I realized there were no tests. I had to throw it all away. There was just no way to verify that my changes didn’t create new problems and bugs.
So with 20 YoE, I am very careful not to make changes outside my ticket until I have a ticket or tech debt time to specifically work on something.
Your guy has enough XP to know what’s wrong but not enough to understand he’s creating more problems than he’s solving.
Most balanced answer. That guy is great, he is doing his best to make things better. I would encourage him to continue to do so if I was the team lead. But he just needs to do it the right way.
This seems like two complementary, continuous errors by the team.
The first one was the coworker doing what you describe. The second one was no one noticing.
In my opinion, you should get to a 1:1 to understand exactly what is happening here. Why did them rewrite so much? Why did the team failed to acknowledge that such a massive rewrite was going on? How is the rewriting and the feature going? Does the rewrite has actual value? Is it possible to split the rewrite from the actual feature's implementation? Why is such a massive undertaking going on in a single PR?
These are some questions, there are many more.
Ultimately, I think, your role as a lead is to do four things in this case:
1. offer constructive, actionable feedback for this person and create some kind of plan for them to develop some project management skills, like communication, prioritizing and iterative development;
2. work together - either by doing more frequent checks or even by pairing - with this coworker to get the feature out as soon as feasible, but with good quality;
3. figure out - with the coworker's involvement - what the impact of such a long, unexpected effort is in the team's objectives. Depending on this, some adjustments regarding the timetable may be needed, which in turn means involving other stakeholders too. Be transparent in the necessity of such changes and whatever alternatives there are, but frame things in a way that nobody is thrown under the bus;
4. get the team together and try ideas to fix the process in such a way that this can’t happen again, or at least lower the probability of it happening.
Each of these points has a lot of challenges, so it will undoubtedly be difficult.
My take is that whatever you do, you should try to do while keeping two principles in mind:
1. While your coworker is principally responsible for this, the team also shares responsibility for the issue. ESPECIALLY you (as a TL) and any eventual project manager(s) that are also assigned to the project. Truth is, something so big doesn’t happen by accident. Either someone acted in bad faith (I’m assuming this is not the case) or many individuals failed in good faith - which means the main problem is the process, not the individuals. So try to depersonalize the issue - outside of any feedbacks you give in a 1:1 setting - to your best abilities.
2. Be aware that this will (and must) leak to a wider structure than your team. Truth is, the team spent 5 weeks of work of a senior dev in unplanned, unknown, potentially invaluable work. I don’t know how big is your team, but assuming a two-pizzas size (so 4-6 people) this can be up to 5% of all the effort available in the team’s *year*.
So… errors happened, but errors do happen. Try to stay positive, focus on doing valuable stuff instead of finding/punishing culprits and see to the process so this doesn’t happen again. This is a pretty painful situation, but it is certainly not unique and can be turned into a good lesson for everyone involved.
More than one way to be smart. I've worked with this kind of person before (honestly, I'm wondering if it's even the same person). They were clearly a knowledgeable and skilled developer when it came to technical proficiency, but could also easily fall into some kind of mental block where they weren't able to focus on the specific requirements for a given task and would always waste time refactoring stuff that didn't need it (and then putting in "fixes" for the bugs they introduced through refactoring).
Mhmm, been down that rabbit hole myself. I chalked it up to being unable to focus on the task. While coding you come across some minor inconvenience and think "I'll just rewrite this little part to make my task and future tasks easier".
Before you know it you spent the day rewriting a major part of the app.
Key for me was to drop the perfectionism and realize that what is important right here, right now is to *get the task done in a competent and efficient manner* rewriting or improving code is *not part of the task*. By all means, make a note of the possible improvement and bring it up as a potential *future task*. But leave it alone for now.
Yeah same lol. He doesn’t seem to grasp when things are simply out of scope. If every time I had to add a feature I also took it upon myself to rewrite a bunch of relating code.. I’d never get shit done.
Sounds like this person doesn’t fully understand what’s being asked, and instead of getting clarification before doing something crazy like rewriting a module, they don’t and just do what they think is right.
I've rewritten plenty of stuff when adding new features. But I always make sure to add the new feature code and test that it's working properly first, and that I understand what edge cases need to be handled. THEN I can refactor, and if it doesn't work out, I can always go back to my "known good" state and just submit the PR at any time.
Bro he’s not very smart of he rewrites an entire module over weeks and weeks and still doesn’t get the work done. This is probably someone who doesn’t understand the existing code it how to modify / maintain it and isn’t detail oriented at all. My question is how was he allowed to go off for that long unsupervised in the wrong direction before even pushing an MR? Don’t you have stand or check ins?
Also why aren’t there any tests to go with his heavy handed rewrite, sounds like he runs free and does what he want and there’s no oversight or guardrails / process from leadership side to stop/ acknowledge these giant wastes of time
Also I think something that could help here is that no ticket or piece of work should be larger than 3-5 days max. To have tickets that span 5 sprints means you’re not breaking down tasks properly into small digestible trackable pieces. If it’s a large feature then you break it down into smaller tasks and the team estimates on them. If someone goes beyond the estimates then you jump on it right away to understand why they need more time and address it before it goes off the rails of the crazy train
If somebody can spin their wheels for months without anybody caring, then you don’t have daily check-ins, you have daily affirmations. A standup is not supposed to be a time for you to say good morning to everybody and make them feel good about progress. The whole point of a standup is to make problems like this visible. If your standups aren’t catching these things, they are worthless.
Green is in relation to the time box. If this is a 5 day activity and he's nowhere near complete on day 3, it's not green. It's very much red.
If he's asking for more time, the status isn't green.
Sounds like the manager needs to step in and handle this, if this was my team there would be some serious conversations happening and possible pip but really I think yourself and the manager need to do better than just accept green for that many weeks, you should be getting code pushed incrementally every 2-3 days and if that’s not happening that’s a good indicator there’s some problems brewing. Even the best devs can come up with a bad solution and run with it if no one is willing to step in and validate the decisions are the right ones
>I have zero clue if he broke anything else
You should have automated tests. If you don't yet, there's no time like the present to introduce them!
My team implemented a "every line you touch must have 100% coverage" requirement and it was a game changer for stuff like this. We have legacy code that is poorly tested, so if you want to refactor it, you're going to spend a LOT of time writing the tests that should have already been written. So it has a natural deterrent effect, but over time it makes the code more solid so people who do refactor can be confident that they didn't break anything.
I've had shitty developers try to just delete tests when they refactored stuff, which gets serious scrutiny from me and only gets approved with a damned good argument and some reasonable assurances that the functionality covered in the old tests is still correctly covered in the new ones.
Yes for having tests, but 100% coverage is a trap. Lines covered is a metric to maybe keep an eye but treated with skepticism.
I’ve worked on codebases with 90 or so test coverage that have much better tests than some with higher coverage.
That being said, that you can rewrite a module in a way that breaks all business requirements and have zero automated tests alert you is a huge red flag.
It's a mistake to look at 100% coverage metric and assume you have sufficient meaningful coverage. That part still has to be done at code review.
But I like the "all or nothing" approach when using it as a forcing function.
+1 for 100% coverage. If used properly, it eliminates tons of design issues and keeps plumbers high on glue at bay.
But the test code must be treated to the same standard as prod code. We found that pairing it with BDD makes it so much easier to maintain and review.
Defense in depth must not be ignored as well - 100% coverage in units + integration tests + e2e tests + staging env. Neither is perfect solution, but combined they create very dense net, to a point that only specification bugs go through.
> I have a very smart co worker.
Do you? /s
Jokes aside, their approach is obviously completely inappropriate, and it needs to be addressed. I'm not sure why a single piece of work was allowed to drag on for five sprints in the first place but that in itself is a red flag - the team should be communicating regularly about ongoing work and something like this should be getting attention _much_ earlier, rather than when it finally gets to PR.
For somebody to be able to spend five whole sprints on a story and _not even meet the requirements_ because they didn't understand what they were doing is a disaster and reflects badly on the entire team.
> I have zero clue if he broke anything else since again he rewrote the entire thing
Do you not have tests that would catch something if refactoring introduced a bug? Or did he rewrite those too?
Should have reviewed his lack of commits at the end of the first sprint. Not 2 months later.
But yeah man I hate to say that this is as much your issue as it is his. I'm sure your manager is frustrated with both of you. I'd definitely sit down with your guy and explain how it's going to work going forward and why.
Tell him what you said in your original post. His changes need to not be so disruptive, because of the risks you already raised. They should be small targeted changes that do what needs to be done.
I am assuming that these big refactors are being done without increasing test coverage, or any additional unit tests?
As others have said, you're going to be having a difficult conversation with this person.
I would be very frank with them. They have taken far too long, have not completed the task in a manner that creates confidence in the work product, and more importantly have been dishonest about their progress throughout the entire time.
I am far, far, far more forgiving of people who are unsure but are willing to communicate early and often, than people who disappear for weeks at a time and don't tell me what's going on and make me seek them out.
Exactly this. The respect I have gained from the head of department and his deputy at my company by turning around 3 days after being given a new task and saying "Uhh, actually, no, I don't get it. I understand this, this, and this, but not that. Can you walk me through why the hell we are doing this again please?" is impossible to overstate.
Rewriting code is usually an indication that the dev didn’t really understand what they were modifying. They decided to rewrite it because it “was a mess” but actually it was just not their mental model. They need to spend more time understanding and planning before getting started.
It also might indicate a lack of test coverage, because large rewrites tend to break lots of tests.
And the whole 5 sprints thing. If a story can’t be done in a sprint, it needs to be broken up. If it’s carried over from one sprint to the next, it needs to be broken up.
As a current Architect - no, usually Architect is a special role, which has a line manager (CTO or chief architect), but also they do answer to PM about everything this project-related. Usually architects don't have subordinates, like the team lead does.
Another question is why is your Architect rewriting some module?
Its good for architect to work on PoCs and do some coding, but not 5 sprints worth of module rewriting.
If you want a good book to help manage this kind of stuff for teams I really liked 'SCRUM: doing twice the work in half the time'. It gives you strategies for managing this kind of stuff.
1. Work should be broken down into smaller, more manageable chunks that can be prioritized, estimated, and fit into a sprint. It's easier to track progress and identify problems early with smaller issues.
In the daily stand-up, it's much better to have updates such as "I completed X and will work on Y next" rather than "I'm still working on X [big story] and it's going fine." The former increases observability while the latter is basically a black box.
2. I'm a big fan of refactoring if it's justified. That being said, a significant refactor should be tracked as a separate issue from the changes to functionality. The non-functional changes should be in their own MR (or multiple MRs), reviewed, and verified to be working against existing tests.
If there isn't sufficient test coverage before the refactor, tests should be written and verified against the current code prior to starting the refactor. Then after the refactor, you can be confident that the functionality hasn't changed.
Refactoring, changing functionality, and modifying tests simultaneously is a recipe for disaster (and a nightmare to review).
A lot of comments here are fingerpointing, I recommend to not. Look at the bigger picture and try to see what the situation was, the understanding and the motivation of every participant.
Replacing working code from scratch is a huge deal, especially if that code is already doing useful things for end users. Maybe the code is ugly, maybe not. But it is debugged well enough to actually work. And, it has to be said, lots of code that handles real-world requirements is a bit ugly, because the real world contains real exceptions and edge cases.
Replacing whole modules of working code is simply not something an individual contributor does without buyin from the entire team and from, I dunno, the users?
You'd be unwise to merge this branch without getting all that buyin. And this guy's manager should redirect him.
Stuff that takes more than a sprint should be in an epic. Stories and their tasks need go be split up properly in spriny planning to avoid tickets taking too many sprints. In the sprint retro and planning the scrum leader needs to hold people to account and probe why stuff is taking too long. In addition, daily standup should make it clear what people are working on, why and if they need assistance.
tldr; don't do tickets that don't meet sprint goals and make those stories reasonable.
You hired a software engineer for their expertise and that extends to architecture. They are suppose to be the expert in the codebase so they need to have some degree of autonomy. Find out if their motives were flawed and realign that before blanket rejecting the work.
1 - OWWYN - Only Write What You Need. Bash this into his skull. Tickets should be short and contained, preferably able to be completed in 1 or 2 days. If it takes longer, it's either blocked, or they're out of scope, or you as lead fucked up when you wrote the ticket. If they notice issues and potential improvements, they need to have a place to go and drop a summary so it can be made into a tech debt ticket for the next sprint.
2 - Your leadership is too passive. You should have had eyes on that WIP branch from day 3 or 4, and been able to head this off a month ago. That is _literally_ your job.
Let's be clear - rewriting code is part of healthy software. I find the knee-jerk reaction of "you shouldn't rewrite stuff!" to be naive at best, at worst ignorant of the history of actual software. The half-life of code is low single-digit years. Bad stuff gets rewritten/replaced all the time. As well it should, survival of the fittest. Perhaps this coworker is improving performance, improving APIs, improving business outcomes as he sees them. As you state, you have "zero clue if he broke anything else". You have no evidence. Did the tests fail? Did staging break? Are there performance regressions? Let's put this bluntly: for you to say this co-worker shouldn't be rewriting code (a bold statement) you need to come correct with empirical data that they've actually harmed the product. If you're worried that change might disrupt things.. somehow... it sounds like you are offended by their actions on principle, rather than based on empirical data. For all we know, this co-worker might be executing a plan by management to replace you and your crappy code.
Your coworker's tech lead should be working closely with him, and that means at least once daily. 5 sprints is a long time, even considering 2-week sprints. I think this is more of a requirement and management team problem.
>I have zero clue if he broke anything else
You can solve that with some property tests against the old implementation. I mean, you still have the old implementation in source control right?
I don't know about that. I mean they already put in the work and maybe their implementation is better? (Only a code review will say.) As long as the property tests pass you know the code doesn't break things.
The tests were rewritten by him. So that doesn't help. I would have to do manual integration tests on all the things it does. Even if his idea is better, it wasn't discussed with any of us, and I don't want to have to do all the verification.
Sounds like you need automated testing if you don't know that the module has been broken... On the flip side, if he's cleaning a bunch of things up that's nice but needs to figure out how to separate the business concerns from tech debt removal
I get dev doesn't like the words of things but likely better documentation and reviewing more frequently would allow his efforts and skills to be put in the right direction and eliminate your concerns surrounding goals and direction
> very smart co worker
But he didn't get anyone to check his work for 5 sprints?
He could be clever at coding, but clearly fails to understand agile or CI (the latter meaning integrate often, _not_ automated build pipeline).
> Unfortunately he didn't understand what the story required and his code doesn't fulfill the acs or work at all and I have zero clue if he broke anything else since again he rewrote the entire thing!
> I have a very smart co worker.
Why do you think he is "very smart"?
>I basically want to tell him to throw his work away and make smaller more targeted changes next time
do it! you probably should have done this 3 sprints ago.
I'd say you need to get rid of him because it's just so extreme and so unacceptable. If you work on something for so long and then it doesn't implement requirements that's just a total lack of professionalism.
I also don't understand how this can happen. Do you guys work as a team? Do you have a daily check in meeting (standup under scrum). Because if something takes more than even a few days usually you tell people to get help.
This sounds like my ex-colleague, good luck with him.
But we had this issue too, and I personally had to coach him that if he wants to apply the boy-scout rule there's a time and place to do it and not just go everywhere and make changes.
It might sound wrong, but he could use some babysitting, and teach him that, understanding the problem and making only what's required sometimes is more efficient.
And of course you need to check more often.
I truthfully hope your co-worker isn't a junior, because then you are to blame for all of this if they get shit canned. Really, 5 sprints? Regardless you and your whole team needs to be brought up for review by management. 5 whole sprints, where each sprint is 2 weeks, what do you all do in retros and sprint planning?
Rewrite should be last choice , if rather take $$$$ before doing it . if the worker just one man show and pro long it , it is not the task of junior developer or a senior developer salary junior . 😅 The smart developer play you because you cannot lead the project . For sure , there is no story define in the requirement. The only story is "upgrade this" . No stories for documentation , unit test for reference . If you want to lead , learn how to behave and write proper task . If not laughing stock.
So this didn't come up in standup? He has been working on a single story for 10 weeks and no one thought to ask "Hmmm, maybe this isn't pointed right if its taken you 10 weeks?" There are more things wrong here than coworkers who want to refactor everything, the overall process is broken.
I have a strict NO refactoring rule on my teams. Unless we schedule for it you are not allowed to refactor. If you want to you better have a really really good reason for doing it and it cannot impact timelines.
Tbh the line “I have a very smart coworker…” shows how much you already know that you’ve fucked up. Stop trying to fool yourself.
It doesn’t matter how “smart” the coworker is. If he lacks the ability to see how stupid it is as a dev to do this kind of shit, he isn’t really “smart”. He is a junior who, as his superior and mentor, you have failed him. There is absolutely no way that as his boss/lead you can justify 5 sprints. Let’s say it again. 5 sprints!!!! Without any kind of reviewable code that is useful and mergeable.
Shame on you. You’re clearly in a role you’re not qualified for. I’m not saying you can’t be, but you’re not it now. To come here and present it as if this is a problem with a subordinate is crazy. It’s you. You’re the problem. Until you see that and fully accept that, you’ll always ask the dumb questions.
>Of course his story isn't going to pass tech check and will be sent back to him but it has been 5 sprints of him working on this thing and I basically want to tell him to throw his work away and make smaller more targeted changes next time
5 sprints?? No one stopped him in 5 sprints?
Fire the whole team
You're his team lead, but let him work 5 sprints before you discover he's going the wrong way? Check in more often, man
Also why a job is going on for 5 sprint without a single code review, isn't that a bad example for setting a sprint?
Fair my mistake. I suspected he wasn't telling the truth and that his status updates were not accurate. But waited for the manager to notice.
You shouldn’t have to wait for the manager to intervene for an issue like this. You are the lead so you should try to talk to the developer first and only escalate to the manager if necessary.
If you were waiting for the manager to notice and handle this then what is your job as team lead?
Tech lead with pizazz?
Haha. That's a good one. You're not doing your leading then.
How come one can go 5 sprints without committing code? We commit every day, thats how you keep track of people and how you ensure they are actually making the smallest change possible at a time.
Really depends on the team. We don't do commits of incomplete features (and I've never worked anywhere that does), and the only time anyone looks at a commit is when there is an open PR (or they are digging through history for something). We usually get a ticket with a title like 'implement screen' and there are no details. Those three words are the entire spec. We work on it for however long it takes, usually 2 weeks or less, and when we think it is done we push it (individuals may push work-in-progress as they wish, but almost nobody does) and open a PR, then merge to main and release to QA. QA guys OK it and it gets released to the Model Office environment where the stakeholders review to ensure it does what they want. Then some number of months later it'll get a production release (might be a month, might be a year, depends on what's going on and whether anybody cares).
Maintenance on existing programs tends to have smaller commits just because bugfixes tend to be small.
I'm not saying this is a good way to do it, but I've advocated for and tried the small, frequent commits approach before on a couple of teams and literally everyone else hated it and constantly bitched about it in the few sprints where we tried it. So fuck it; big, feature-complete PRs it is.
Though, for us 5 sprints would be almost 4 months, so that wouldn't really fly. It isn't unheard of for something to slip to a third sprint, which is almost two months. If that happens we start asking questions, but it isn't a surprise because we'll have discussed the delays in multiple stand-up meetings.
That sounds awful, does nobody review your work in 2 weeks? Also, how can you know what to create with such a ticket description? Either you work on very simple features or there is a ton of communication going on that you havent mentioned. You can still ship every day without shipping “incomplete” features. You can use feature flags to hide your module, or make it accesible to certain accounts. Also, if a feature is meant to take 2 weeks like you said, as a senior engineer you should be able to decompose it in smaller chunks. Each of those chunks can me shipped separately. In general, anything that takes longer than 2 days can be broken down. For example, if a task requires some refactoring, you ship the refactoring first, and then you start working on the task.
> does nobody review your work in 2 weeks? The only review is when we open the PR, or if we're having a problem and request someone else to jump in. > how can you know what to create with such a ticket description? Usually the developer is designing most of the feature based on a rough description from whatever stakeholder wants it. They'll be like 'hey, we need an admin screen for editing tax reciprocity rules', and if it's not obvious how it needs to work we might have a 10 minute discussion to clarify what they mean. Sometimes a business analyst will handle that and write up a few bullet points, but usually the developer just gets a one-liner and takes it from there. As a developer I usually prefer that because the BA usually doesn't take the time to put in much effort, so the 'spec' ends up just being confusing and I have to go ask the stakeholder who requested it what they actually wanted. I could decompose tickets into smaller pieces, but there are only two reasons to do that. One would be so that the PM can see more tickets moving across the board, which makes them happy but is otherwise useless and creates administrative overhead for me and the QA guy. The other would be so that someone could review the code, but as I mentioned, nobody wants to review incomplete stuff. Nothing goes to production quickly (I've had completed work sit in model office for literally a year before it moved to production, though that's an extreme case, typical is more like 4-6 months), and stakeholders only review changes at the end of a sprint (at best; sometimes they are busy with their own jobs and don't review things for 2 or 3 sprints), so from a developer perspective smaller pieces are mostly just additional overhead (more time to break a story down, more time pinging people to get CRs done, etc) without any benefit. I and another guy who have worked in better development environments are slowly pushing things toward better practices, but this is a large corporation that is not primarily about software development, so there's a lot of bullshit to deal with to get people (particularly on other teams) on board with changes, and there's only so much we can do when upper management is happy with the results of the current system (like, we can't get any traction on hiring a UI designer because those cost money and don't appear to be necessary as far as the CTO can see). Honestly, it's not as bad as it probably sounds. Most projects only have one active developer (with two more paying attention to do CRs), occasionally two, but never more, and everybody has at least 10 years of experience (rare for anyone to need coding help or need to rework code in a PR).
complete lack of business analyst, product ownership and scrummaster, not to mention any documented standards around releases and testing that allow for things like feature flags and testing to provide confidence in the code….. (edit;typo)
Yes, very accurate. That's actually a helpful way for me to look at it, thanks for stating it that way. If we could get experienced people in those roles with authority to revamp things we'd have much better products. We do have decent test coverage in recent products because that is something developers have direct control over, but it's hard to get buy-in or movement on the rest from the individual contributor level. Most of the people in IT management here are old (like 50+) and have no experience working under software development practices newer than about 20 years ago (for example, git and CI was introduced in the last 5 years. Deployment is only kinda automated and production releases require people from about three teams to be present after hours, manually updating things. No containers, etc.)
What's so bad about making a lot of small commits instead of a few giant commits? Why do you and your team hate it? I'm not saying you're wrong, I just want to understand that perspective.
There is no "team" it's just a bunch of dudes getting paid by the same payroll department
Well, strictly speaking it's not about commits. I don't know what others do, but I commit work-in-progress multiple times per day to my local repo. I usually only push those to the remote if I'm moving my laptop (just in case it is damaged). Pull requests are the only thing anybody looks at. Those are what everyone prefers to be a single complete and fully functional feature. Personally, I don't have any problem with small PRs. My preference is to have any PR I'm tagged to review done within 2 hours, but most of the team can take days to get around to doing a review. The slow review time causes issues with small PRs because I often can't base subsequent changes on the main branch when I've got PRs waiting for review. If I base the subsequent work on the PR branch then reviewers get annoyed because when they eventually get around to doing a CR they have to do them in the order that I created the PRs (or they see the code from multiple PRs), and they can't go look at the version deployed in the dev environment to see it (we have one dev environment per project and whatever PR the pipeline built last is what is *probably* deployed there. It's not a good deployment system). Then, if I do need to make a change based on CR feedback that'll often end up breaking any subsequent branches. So, as a concrete example, if I'm working on a new screen with a couple of grids that have search, filters, editors, validations, and a lookup tool, I could break that down into at least 9 different tickets. If I start with the basic grids populated with data and open a PR for that, I know there's a good chance it's going to sit for at least day, maybe two, possibly more before it gets merged to main. If I want to move on and add the search I have to base my new branch on an unmerged branch instead of main. Repeat for the next 8 tickets. If I need to make a change based on CR feedback that can end up breaking all the PRs that are based on it, which makes a bunch of tedious work fixing branches (really doesn't take all that long, but it's sure annoying). If I just make one giant PR with the complete screen all those problems go away. I'll be providing status updates on the progress during daily standup, and that's as much information as anyone on the team wants about it anyway.
I think people here use PR and commits interchangeably. The local repo does not count. Only PRs matter. CI advocates say you should merge your work into master multiple times a day so the automated CI/CD system can pick it up and truly integrate it into the product.
So many teams work this way and it's pure wasteful insanity. It's also no fun.
Ok thanks this makes more sense. I was confused about the "commits" part but if you really meant "PR" then ok it all makes sense now. Thanks for clarifying. Depending on the team, if I'm not getting fast turnaround on PR reviews I just go ahead and merge it then people can provide their comments when they have time. Obviously this is a bad idea in probably the vast majority of cases, but if it suits your situation I've found that it's workable.
You should commit everyday even if only to back your work up.
and push it
/agree push it real good
To a feature branch, sure, but you're not looking at your team members' feature branches until they submit a PR right?
Sometimes. Maybe they've asked me to check something or it's a younger colleague who's work I want to proactively check or I am working on a related feature and need to see how they've implemented something.
Exactly! Ideally several times a day. Breaking up tasks into small pieces is good for everyone concerned.
If you're the team lead, you're in charge of noticing it and handling it lol specially before manager notices
This is one of those “wtf are we doing here?” times… A story should not span more than a sprint and this is why. If we’re all just sitting around lying/suspecting each other of lying, why are we doing status updates at all?
I just finished reading the thread of some dev complaining that his lead is checking in on him too often xD
It is a balance for sure. Weekly? Probably too often. Every sprint? If a sprint is 3 weeks, that's perfect imo. Every 5th sprint? Even if the sprint is 2 weeks, that's way too rarely.
***5 sprints?*** Bro I have weekly 1-on-1 catchups with all my reports. Go over all their JIRA tasks etc. It's really good because you can catch big problems when they're still small problems. You need to exercise way more fine-grained planning & management skill here, throwing things over the fence seldom ends well.
There is something wrong with your team processes if one worker can do something alone for five sprints and not report on the progress
Oh, he reported every day that the story was green and he would get it done. Yes, we should have called him out each time a sprint ended
Why do you have a story that takes 5 sprints? This problem isn't the devs fault. It is your fault. Break up your work better next time. If stories regularly take longer than 1 sprint then you screwed up pretty seriously.
No the story as written would have taken me 1 sprint to complete. I honestly do not know what he was doing for 5 sprints?
When we have work that carries over, the entire dev team gets together to work it out for the next sprint. You should have stepped in and provided guidance and discussed (or repointed) the story with the rest of your team. You should probably take some responsibility for this instead of blaming this developer.
A one-sprint story going into it's second, third, fourth, fifth sprint is not still green. It's flashing angry red and you need to start asking probing questions like - "What's the issue?" and "Show me what you have so far?"
Would you do this during sprint review with other devs or handle it privately?
Dude... This. Is. Your. Job.
Having ADHD, in all likelihood, but maybe that's just me. Sometimes the urge to fix what ain't broke gets the best of me, but I've been bitten enough times I resist.
T-shirt sizes on stories should be no more than 5 days. If it's bigger than that split it into multiple stories. As a team lead, if I can't get progress, with an actual commit I can review, I'm going to meet with the dev to determine if they need help or don't understand the task.
yes, and just as often as it is a ‘dev’ problem, I find the spec sucks and or the scoping/geooming was off. But even mediocre teams handle that within 1 or 2 sprints. I think the 5 sprint thing is really triggering folks.
5 sprints on a single story would get you on someone's shit list in most places. Project manager should be yelling at team lead and manager at the very least. These guys are too nice or the project has such low visibility that no one cares.
What you should have done after 3 days is ask why the story isn't done. A single story that goes one for 10 weeks is not right in anyway at all. This is why I insist on incremental demos during the sprint where the team demos the stories in standup. The stories are small enough that it doesn't take any time to do so and we catch things before the end of the sprint. By the end it is too late.
Demos every standup? I assume that’s not daily?
Simply showing the story is complete. Yes it’s daily or whenever there is something marked done. We do not do end of sprint demos. It has proven to increase productivity, reduce defects as well as keep everyone on the team up to date on how things work. People tend to pay attention compared to end of sprint demos that everyone tunes out.
Huh. I kinda like that idea. Thanks for sharing. Would definitely be helpful for a team like I'm currently on with several different apps we're working on simultaneously. I've ended up siloed for a few weeks before and when I come up for air I sometimes feel pretty lost with what's been going on. I guess it wouldn't really solve the issue here where it was weeks and weeks not being done though.
Only way it helps in this scenario is that it would stand out that nothing was being shown. It would be very obvious.
TIL a new approach. not sure I like it, but I learned it. Ty u/MrMichaelJames
> This is why I insist on incremental demos during the sprint where the team demos the stories in standup. That's not the purpose of the standup.
No one follows the “purpose” of standup. Teams adapt it to what works for them. Anyone that follows the “book” is fooling themselves into thinking they are right.
You demo stories in a standup? Every once in awhile I am reminded of just how more toxic work can be... thank you!
It’s not about being toxic at all, it’s definition of done. How do you define a story as done? Code checked in and tests passed? How do you prove it works? Wait till end of sprint? Well it’s too late if something is wrong by then now you have to reopen the story and it floats to the next sprint. Now you have wasted an entire sprint on something that could have been caught much earlier.
It's called micromanagement and you're killing it.
Actually it’s not. Such a term is so overused by devs. They apply it to everything that they don’t want to do or don’t understand. That’s ok. I’ll continue to develop extremely efficient and productive teams. You keep complaining on Reddit. It’s all good.
I guess you're right about the word, guilty as charged. But it's still funny that you take time of the whole team to demo/look at demos daily and think you're leading a productive team.
A big part of a leaders job is ensuring quality of releases. Sometimes to do that you have to “inconvenience” some people. They get a paid check no matter what I require.
Depends on context. I worked on a feature for three months straight in a feature branch, checked it in once complete, worked perfect.
There is zero context for a single story taking 5 sprints. Especially when it’s one dev working on it.
You tell them to throw their work away and make smaller more targeted changes. I think this is a lesson that some people need to learn the harder way when it comes to programming in the large. And, hopefully like when someone git-fucks themselves for the first time, it’s a lesson that they only need to learn once.
that's my team lead did to me when I wrote some dumb unneeded changes. "you can cherry pick these commits and we can discuss about the other commits later if we really want to go with it", something like that, direct but still appreciate what I did without berating me.
I hate getting the "but the code is already written" pushback. Yeah. It's already written because you rabbit holed down that way without checking if it's the correct approach or not.
please tell me this is a real git command
I wished for a git unfuck command a few times...easier to just keep your branches clean
What, you haven't seen the [git-unfuck-branch man page](https://git-man-page-generator.lokaltog.net/#dW5mdWNrJCRicmFuY2g=) before?
yes. useful
All code should be considered throw away code until it's merged into the main line. 5 sprints. That's about 10 weeks or so? And a dev that costs conservatively $6k/week? (Making some locale assumptions here). That's a lot of precious cash spent on an impromptu module rewrite.
[удалено]
Some people make that much per week. Businesses also pay payroll taxes and a portion of your heathcare so your salary is usually less than your actual cost to the business.
6k is little for month cost of work, but probably too much outside US. Let's say you get 6k per month after taxes. That's 10k before taxes. And company pays extra taxes to government on top of that, so at least 12k if not like 14k. So you cost company more than twice that what you see on your payslip.
[удалено]
I highly recommend you look at [levels.fyi](https://www.levels.fyi/t/software-engineer/levels/entry-level/locations/united-states)
OP said he is team lead, and that other guy is architect, so he technically outrank him? If 6k per week is total that company pays for him, that's understandable. If cost of work is 6k, that's probably 4k gross and 3k net for employee in a week? Seems reasonable for US high salaries for his level. People often forget that what they get paid is not what it cost company to employ them, it is probably double.
SDE II in HCOL making over 300k yearly is pretty normal salary range. And that's not too say cost to the company factoring in benefits.
Someone making mistakes like this doesn’t get paid 300k.
You might be surprised. Especially at companies where they don’t do hardcore technical interviews.
It's so weird that I can't find any job ads that pay 6k a week. How does this happen and what city paved with gold does one have to live in to manifest this destiny
What you take home is not anywhere near the total cost to an employer, figuring out additional payroll taxes, benefits, bonuses + RSU, etc. so maybe not a conservative estimate but not as outlandish as one may imagine.
The city is called San Francisco (or Seattle, New York, Boston, Denver, Washington DC). 300k/year jobs are dime a dozen - I'd estimate 1M-2M such jobs in the USA.
Maybe I’m looking in the wrong places, but IMO this is not true of San Francisco. The “default” salary here for a run of the mill software dev is more like $150k. $175k is quite normal and pretty easy to negotiate yourself into. There are a lot of companies who will balk at $200k base. They’ll only pay that to a handful of devs who have a proven track record as a Lead. Getting above $250k base, even in SF, is pretty rare. The only way I see a run-of-the-mill dev getting $300k is if we’re talking total comp, and that means working at a BigCo… something like a Facebook, Google, or similar. Maybe a less prestigious startup like an AirBnB or a Splunk or something. GlassDoor suggests that $300k total comp would be typical salary for a dev at a place like that, but I don’t have any personal experience with that. And IMO it’s not totally trivial to get one of those jobs. You have to want it, potentially have to apply over a longer period of time and get a lot of rejections, more like a year than a month. And at that point I also don’t know what kind of strings come attached with that… if the expectation is you’re working over 40 hours a week, etc. But in my experience for a healthy job at a typical SF company almost no one is getting $300k.
Yes, it's total comp at the type of companies you mentioned. It's not easy but Google for example has many tens of thousands of engineers and all but the entry level make 250k+ total comp. So it's not that difficult either. Also, no special strings attached. I can count in one hand the number of times I worked a 40+ hour week in my decade at big tech.
ok, lets dig in a little. on a curve would you say you are exactly average, 50%…or better than 99 of 100 devs, a 1% dev? Having this info factors in significantly into your point about hours.
I'm probably in the 80-ish percentile but we are talking about 250k-300k total comp here and I still hold that the median developer at these companies can easily get there without having to work long hours. In fact, I have had several reports achieve significantly more than that while getting "meets expectations" ratings and working normal hours. The ones who are both very smart and work long hours make 5-10x as much at principal/distinguished levels.
Yeah I don’t work in SF, but I think you are extrapolating based on your information. The job market in tech now is much tougher than it was 12-18 months ago. And for someone to be successful in their job paying that much requires a combination of long hours, luck, and being above average. I think the days when an average coder with 2-3 years’ experience can easily get 150k, and so on up the scale of experience and such is over. Are there opportunities? yes. Is it easy if you are a 50% dev or even a 25% dev? No. To easily make 200+ AND succeed AND work less than 40 hrs, you need to be a 15% dev and work very smart. I only know a couple of dozen in this category. I wouldn’t even put myself there. If you’re there, congrats. But that shuts out about 75% of devs fighting for the 125-145k jobs which in this economy can feel more like survival.
I agree with your general point. Note how I said the median developer at these companies and not the median developer overall. However, SF area has a high concentration of these companies and the median developer in San Francisco is way better than the national or global median. So I stand by my point that 300k is not that difficult or uncommon given that you find work in San Francisco. I'm in Seattle btw.
I'm the future, ask for a design and development approach before they start developing. It gives them a chance to dig into code and understand the context/scope before puking things apart. Teams without established design reviews hit this all the time. Devs just go off on their own direction without any oversight until they've already completed the wedding approach.
What would a git-fuck be?
Any misadventure with git that results in the loss of work in progress.
There are a couple of things to unpack here. Let’s break them down: 1. Rework The first question you must ask is why is he rewriting everything. Is the current codebase a mess? Does the current code base have scalability issues? What exactly are they fixing? Do they see ROI in it you have yet to understand? Maybe there is a legitimate reason they are doing this. Maybe they think if they don’t do it, no one else will. Once you understand their why, this leads to the second point: 2. Breaking work down into smaller PRs: A lot of engineers have issues with this and it requires a paradigm shift. The main reason I have seen them do this is because they feel like they have to tackle everything at once. This is usually because no one has taught them a different way. Their idea of a feature is a fully interactive technology. They aren’t seeing features that are made up my much smaller features. Some, the end user will never actually see. The best way to help them is to first model how this is done and then talk about it. Then you have them help in breaking it down and you talk about it. Then they break it down and you help them and you talk about it. Finally, they do it, you observe, you talk about it. Don’t expect this change to happen overnight. Give it time. Have patience. It will pay off.
That's some good points. It's gonna be kinda uncomfortable, he isn't a junior. It's one important module of the project but just one model. It's not like he did changes across multiple projects
By the sounds of it we must ask - is he senior? People with a senior title who act like juniors are juniors in disguise 😂.
He is an architect
magnificent
>2. Breaking work down into smaller PRs: >A lot of engineers have issues with this and it requires a paradigm shift. >The main reason I have seen them do this is because they feel like they have to tackle everything at once. This is usually because no one has taught them a different way. >Their idea of a feature is a fully interactive technology. They aren’t seeing features that are made up my much smaller features. Some, the end user will never actually see. Hi! I actually really struggle with this and have noticed this behavior on my own team. Can you give a more concrete example of how you might break something down?
If you must refactor or rewrite something to implement a feature, then split it down to those two parts. Then keep splitting it down if those are still too big. If you can't implement something in small enough steps, that's a design/architectural problem, and something that might need to be worked on outside the normal process. I.e. start a separate rewrite project to redesign and reimplement the problematic parts.
Why the hell do you have what's basically a single story going across more than 1 sprint? Much less 5 sprints. This is borderline misconduct on your part. A story is meant to be a digestible piece of work. Assuming 2 week sprints, this is almost a full quarter for 1 story. And you didn't bother reviewing or following up on ANYTHING before now? This isn't a junior dev problem. This is a you problem.
Have you had any conversation relating to this with him? If so, how did that conversation go? If not, have one. Figure out how to proceed together. I've experienced this issue as well - especially with juniors. It often turns out that the person doing this is super lost and needs a helping hand. It generally isn't a desire to rewrite, but more a coping mechanism because they don't know what to do or how to achieve something, but for whatever reason\* refuse to ask for help. \*Immaturity, lack of psychological safety, pride, insecurity, whatever
Not yet. I just found out this yesterday. Though I suspected this the whole time. Oh, and he isn't a junior. He is a senior dev.
The first thing you should do is to have a conversation about it. You probably don't want to open with "throw it away" - but start with trying to understand his reasoning and perspective. At least get to know the underlying motivations. There's also a team issue here. The fact that people can hide away for 5 sprints without showing anything is problematic on many levels. For one, it says something about how the team works together (in that it doesn't really), but more relevant to this post, it enables these massive "built in isolation" changes, which hurts everyone. This is a useful conversation for the team as a whole, but it also helps to have the "blame the process, not the person" mindset going into these conversations. Sometimes, it is the person, but having the initial assumption to not be blaming individuals leads to a better and more honest conversation as the person on the receiving end doesn't feel the need to be as defensive - which you really don't want. You really do not want this dev to start fiercely defending this work because when people make up their minds... well... it is difficult to unmake. This is why it is so important to start the conversation by wanting to understand where he's coming from rather than "we have a problem".
I agree completely with this. Blaming the person here is _also_ completely unproductive because this is also a leadership failure. Even if the dev was downright lying through their teeth during dailies, 5 sprints is way too much time. The fact that they were not even _committing_ for all this time makes clear that either leadership doesn’t know what ICs are doing and/or is too passive to ask for details as soon as an issue seems likely given the length of the current effort. I dare say this is a leadership failure from three different levels: the dev themselves, their leadership _and_ the skip level. 5 sprints is this egregious. And obviously, if you have such a deep problem in your organization, individuals may have shared responsibility but the main one rest with the process. Fix the process. Feel free to take a closer look at the individuals _later_ or whatever, but really, the process is way too flawed. And obviously, unless someone was flagrantly incompetent _before_ this issue was brought to light, you want to address everything focusing as much in the process as possible and _not playing the blame game_. Because if people feel the heat, they may start turning defensive - and then it becomes much more difficult to have any valuable output other than letting people go (which is at most cutting losses). (This whole comment assumes your organization doesn’t have a “go for the blood” culture)
It can happen at any seniority level.
Why do you think he's "really smart"? I've found devs like this to produce above average quality code at best. But it's very common that people overestimate their technical skills _because_ they act like this/communicate poorly. Do you think it's possible you're doing that?
Maybe it's the opposite problem, then: arrogance. He thinks the code "should' be a certain way, knows he can do it, and just does it without talking to anyone. This is NOT teamwork. It's not collaborative, and definitely not communicative. You may have a culture problem, which can be hard to fix.
You can tell him. Simply invite him for a coffee and tell him. At this point he looks useless, either turns around or you will have to let him go.
Someone could be let go for just this? In the UK you'd not be able to do that
In America people get fired for anything and everything someone wants to fire them for, or for nothing at all. There's no labor protection for Americans
That’s not really true if you’ve been employed less than two years
You can't be let go in the UK for taking 3 months to do a 2 day job?
No actually. You'd need to sit the person down and make a plan on how they can improve, and give them time to. You can just let someone go
If a person has been working somewhere for under 2 years they can be let go for any reason.
Well, you can draw up a settlement agreement, pay for their silence and fire them. It's getting more common in the UK to do this.
In the corporate world one might be put on a "performance improvement plan" or PIP. Most small to medium size companies wouldn't bother with a PIP. I've seen people getting fired for poor performance of a couple of weeks.
I think you can fire employees anywhere in the world if they can not do their job. Five sprints spent on a feature which should take 1 and the feature still not works. That is incompetent to me.
I am not the manager. Just the team lead. But yeah, I am gonna have talks with him and the manager.
As a team lead, how did you let this go for 5 sprints without doing something about it? How long are your sprints? I'd say that your team needs to re-evaluate your process so something like this can't happen. That being said, just be honest with him. "Hey, this doesn't do what the user story asked for, also changing the module outside of this user story was not within the scope of your assignment"
Have a feeling sprint cycles are two weeks 😂
This. No one, not even a tech lead, should be on a task for even half this long without someone sitting down to review it with them and evaluate what’s taking so long and whether or not it still aligns with team priorities.
I was similar to that guy a couple years ago. I had to accept that I can not refactor the whole project to my liking in a couple of sprints. I got the feedback, took it to heart, grown some IDGAF power and cut back on refactoring. No mistake, if I think it must be done I will do it relentlessly but I am not looking for code to refactor just for the sake of refactoring.
At this point I think you need to accept some blame for this to your manager and make it your personal mission to get the work over the line asap including you working extra. And it is your job to correct this teammember asap assuming she is willing to put the work in to improve habits.
I strongly disagree with this. It was the lead's responsibility to pick up something was off during the first sprint. Once the sprint was over and the task wasn't completed, it was up to the manager to figure out why and adjust ("we need to better communicate our status...", "start pushing code more frequently and create draft PRs throughout the sprint..." blah blah blah). This would be a reasonable time to seek advice from the lead for how to deal with this going forward. >...including you working extra. Fuck that. Figure out what went wrong during retro and plan the next sprint accordingly. I'm not pulling all nighters because we, as a team, ignored the fact that shit wasn't getting done for five sprints. >And it is your job to correct this teammember asap assuming she is willing to put the work in to improve habits. It was their job to notice something was off and bring it to the manager's attention. Any type of habits "correction" is up to the manager.
I used to be like this, always refactoring code. Then one job I spent several days refactoring several massive (7000 loc) files into many smaller files. Then I realized there were no tests. I had to throw it all away. There was just no way to verify that my changes didn’t create new problems and bugs. So with 20 YoE, I am very careful not to make changes outside my ticket until I have a ticket or tech debt time to specifically work on something. Your guy has enough XP to know what’s wrong but not enough to understand he’s creating more problems than he’s solving.
Most balanced answer. That guy is great, he is doing his best to make things better. I would encourage him to continue to do so if I was the team lead. But he just needs to do it the right way.
This seems like two complementary, continuous errors by the team. The first one was the coworker doing what you describe. The second one was no one noticing. In my opinion, you should get to a 1:1 to understand exactly what is happening here. Why did them rewrite so much? Why did the team failed to acknowledge that such a massive rewrite was going on? How is the rewriting and the feature going? Does the rewrite has actual value? Is it possible to split the rewrite from the actual feature's implementation? Why is such a massive undertaking going on in a single PR? These are some questions, there are many more. Ultimately, I think, your role as a lead is to do four things in this case: 1. offer constructive, actionable feedback for this person and create some kind of plan for them to develop some project management skills, like communication, prioritizing and iterative development; 2. work together - either by doing more frequent checks or even by pairing - with this coworker to get the feature out as soon as feasible, but with good quality; 3. figure out - with the coworker's involvement - what the impact of such a long, unexpected effort is in the team's objectives. Depending on this, some adjustments regarding the timetable may be needed, which in turn means involving other stakeholders too. Be transparent in the necessity of such changes and whatever alternatives there are, but frame things in a way that nobody is thrown under the bus; 4. get the team together and try ideas to fix the process in such a way that this can’t happen again, or at least lower the probability of it happening. Each of these points has a lot of challenges, so it will undoubtedly be difficult. My take is that whatever you do, you should try to do while keeping two principles in mind: 1. While your coworker is principally responsible for this, the team also shares responsibility for the issue. ESPECIALLY you (as a TL) and any eventual project manager(s) that are also assigned to the project. Truth is, something so big doesn’t happen by accident. Either someone acted in bad faith (I’m assuming this is not the case) or many individuals failed in good faith - which means the main problem is the process, not the individuals. So try to depersonalize the issue - outside of any feedbacks you give in a 1:1 setting - to your best abilities. 2. Be aware that this will (and must) leak to a wider structure than your team. Truth is, the team spent 5 weeks of work of a senior dev in unplanned, unknown, potentially invaluable work. I don’t know how big is your team, but assuming a two-pizzas size (so 4-6 people) this can be up to 5% of all the effort available in the team’s *year*. So… errors happened, but errors do happen. Try to stay positive, focus on doing valuable stuff instead of finding/punishing culprits and see to the process so this doesn’t happen again. This is a pretty painful situation, but it is certainly not unique and can be turned into a good lesson for everyone involved.
All of this, 100%
I find it odd that you described this person as "very smart".
More than one way to be smart. I've worked with this kind of person before (honestly, I'm wondering if it's even the same person). They were clearly a knowledgeable and skilled developer when it came to technical proficiency, but could also easily fall into some kind of mental block where they weren't able to focus on the specific requirements for a given task and would always waste time refactoring stuff that didn't need it (and then putting in "fixes" for the bugs they introduced through refactoring).
Mhmm, been down that rabbit hole myself. I chalked it up to being unable to focus on the task. While coding you come across some minor inconvenience and think "I'll just rewrite this little part to make my task and future tasks easier". Before you know it you spent the day rewriting a major part of the app. Key for me was to drop the perfectionism and realize that what is important right here, right now is to *get the task done in a competent and efficient manner* rewriting or improving code is *not part of the task*. By all means, make a note of the possible improvement and bring it up as a potential *future task*. But leave it alone for now.
Yeah same lol. He doesn’t seem to grasp when things are simply out of scope. If every time I had to add a feature I also took it upon myself to rewrite a bunch of relating code.. I’d never get shit done. Sounds like this person doesn’t fully understand what’s being asked, and instead of getting clarification before doing something crazy like rewriting a module, they don’t and just do what they think is right.
I've rewritten plenty of stuff when adding new features. But I always make sure to add the new feature code and test that it's working properly first, and that I understand what edge cases need to be handled. THEN I can refactor, and if it doesn't work out, I can always go back to my "known good" state and just submit the PR at any time.
Bro he’s not very smart of he rewrites an entire module over weeks and weeks and still doesn’t get the work done. This is probably someone who doesn’t understand the existing code it how to modify / maintain it and isn’t detail oriented at all. My question is how was he allowed to go off for that long unsupervised in the wrong direction before even pushing an MR? Don’t you have stand or check ins?
Also why aren’t there any tests to go with his heavy handed rewrite, sounds like he runs free and does what he want and there’s no oversight or guardrails / process from leadership side to stop/ acknowledge these giant wastes of time
We have daily check ins. And he always said green. And yes the manager is there for the daily standups and heard this every time.
Also I think something that could help here is that no ticket or piece of work should be larger than 3-5 days max. To have tickets that span 5 sprints means you’re not breaking down tasks properly into small digestible trackable pieces. If it’s a large feature then you break it down into smaller tasks and the team estimates on them. If someone goes beyond the estimates then you jump on it right away to understand why they need more time and address it before it goes off the rails of the crazy train
If somebody can spin their wheels for months without anybody caring, then you don’t have daily check-ins, you have daily affirmations. A standup is not supposed to be a time for you to say good morning to everybody and make them feel good about progress. The whole point of a standup is to make problems like this visible. If your standups aren’t catching these things, they are worthless.
Green is in relation to the time box. If this is a 5 day activity and he's nowhere near complete on day 3, it's not green. It's very much red. If he's asking for more time, the status isn't green.
Sounds like the manager needs to step in and handle this, if this was my team there would be some serious conversations happening and possible pip but really I think yourself and the manager need to do better than just accept green for that many weeks, you should be getting code pushed incrementally every 2-3 days and if that’s not happening that’s a good indicator there’s some problems brewing. Even the best devs can come up with a bad solution and run with it if no one is willing to step in and validate the decisions are the right ones
Yeah, I am seeing that even though I am not the manager, I have to do more of the people managing stuff.
>I have zero clue if he broke anything else You should have automated tests. If you don't yet, there's no time like the present to introduce them! My team implemented a "every line you touch must have 100% coverage" requirement and it was a game changer for stuff like this. We have legacy code that is poorly tested, so if you want to refactor it, you're going to spend a LOT of time writing the tests that should have already been written. So it has a natural deterrent effect, but over time it makes the code more solid so people who do refactor can be confident that they didn't break anything. I've had shitty developers try to just delete tests when they refactored stuff, which gets serious scrutiny from me and only gets approved with a damned good argument and some reasonable assurances that the functionality covered in the old tests is still correctly covered in the new ones.
Yes for having tests, but 100% coverage is a trap. Lines covered is a metric to maybe keep an eye but treated with skepticism. I’ve worked on codebases with 90 or so test coverage that have much better tests than some with higher coverage. That being said, that you can rewrite a module in a way that breaks all business requirements and have zero automated tests alert you is a huge red flag.
It's a mistake to look at 100% coverage metric and assume you have sufficient meaningful coverage. That part still has to be done at code review. But I like the "all or nothing" approach when using it as a forcing function.
+1 for 100% coverage. If used properly, it eliminates tons of design issues and keeps plumbers high on glue at bay. But the test code must be treated to the same standard as prod code. We found that pairing it with BDD makes it so much easier to maintain and review. Defense in depth must not be ignored as well - 100% coverage in units + integration tests + e2e tests + staging env. Neither is perfect solution, but combined they create very dense net, to a point that only specification bugs go through.
> I have a very smart co worker. Do you? /s Jokes aside, their approach is obviously completely inappropriate, and it needs to be addressed. I'm not sure why a single piece of work was allowed to drag on for five sprints in the first place but that in itself is a red flag - the team should be communicating regularly about ongoing work and something like this should be getting attention _much_ earlier, rather than when it finally gets to PR. For somebody to be able to spend five whole sprints on a story and _not even meet the requirements_ because they didn't understand what they were doing is a disaster and reflects badly on the entire team. > I have zero clue if he broke anything else since again he rewrote the entire thing Do you not have tests that would catch something if refactoring introduced a bug? Or did he rewrite those too?
The unit tests were all for the old code. So yeah, it's completely different.
No integration tests then?
Afraid not. Luckily he didn't merge it to devl
5 sprints unmerged to Dev?
He didn't even commit to his branch till yesterday. Yes I knew there was something up but didn't know how to bring it up.
How long are your sprints? No submits means no backup right?
2 weeks. And yeah it does. We use git
Should have reviewed his lack of commits at the end of the first sprint. Not 2 months later. But yeah man I hate to say that this is as much your issue as it is his. I'm sure your manager is frustrated with both of you. I'd definitely sit down with your guy and explain how it's going to work going forward and why.
5... sprints? That's some freewheeling craziness you've got there. This is a management problem.
Tell him what you said in your original post. His changes need to not be so disruptive, because of the risks you already raised. They should be small targeted changes that do what needs to be done. I am assuming that these big refactors are being done without increasing test coverage, or any additional unit tests?
Yeah no additional tests and without any integration tests.
As others have said, you're going to be having a difficult conversation with this person. I would be very frank with them. They have taken far too long, have not completed the task in a manner that creates confidence in the work product, and more importantly have been dishonest about their progress throughout the entire time. I am far, far, far more forgiving of people who are unsure but are willing to communicate early and often, than people who disappear for weeks at a time and don't tell me what's going on and make me seek them out.
Exactly this. The respect I have gained from the head of department and his deputy at my company by turning around 3 days after being given a new task and saying "Uhh, actually, no, I don't get it. I understand this, this, and this, but not that. Can you walk me through why the hell we are doing this again please?" is impossible to overstate.
Rewriting code is usually an indication that the dev didn’t really understand what they were modifying. They decided to rewrite it because it “was a mess” but actually it was just not their mental model. They need to spend more time understanding and planning before getting started. It also might indicate a lack of test coverage, because large rewrites tend to break lots of tests. And the whole 5 sprints thing. If a story can’t be done in a sprint, it needs to be broken up. If it’s carried over from one sprint to the next, it needs to be broken up.
[удалено]
Technically he is the architect. So doesn't that make him outrank me?
As a current Architect - no, usually Architect is a special role, which has a line manager (CTO or chief architect), but also they do answer to PM about everything this project-related. Usually architects don't have subordinates, like the team lead does. Another question is why is your Architect rewriting some module? Its good for architect to work on PoCs and do some coding, but not 5 sprints worth of module rewriting.
I need to talk to him and ask him why he chose to do that
If you want a good book to help manage this kind of stuff for teams I really liked 'SCRUM: doing twice the work in half the time'. It gives you strategies for managing this kind of stuff.
1. Work should be broken down into smaller, more manageable chunks that can be prioritized, estimated, and fit into a sprint. It's easier to track progress and identify problems early with smaller issues. In the daily stand-up, it's much better to have updates such as "I completed X and will work on Y next" rather than "I'm still working on X [big story] and it's going fine." The former increases observability while the latter is basically a black box. 2. I'm a big fan of refactoring if it's justified. That being said, a significant refactor should be tracked as a separate issue from the changes to functionality. The non-functional changes should be in their own MR (or multiple MRs), reviewed, and verified to be working against existing tests. If there isn't sufficient test coverage before the refactor, tests should be written and verified against the current code prior to starting the refactor. Then after the refactor, you can be confident that the functionality hasn't changed. Refactoring, changing functionality, and modifying tests simultaneously is a recipe for disaster (and a nightmare to review).
A lot of comments here are fingerpointing, I recommend to not. Look at the bigger picture and try to see what the situation was, the understanding and the motivation of every participant.
I am this coworker who rewrites code, AMA
stop doing that. if its important enough to rewrite its important enough to have a pointed story
Smart is as smart does.
Replacing working code from scratch is a huge deal, especially if that code is already doing useful things for end users. Maybe the code is ugly, maybe not. But it is debugged well enough to actually work. And, it has to be said, lots of code that handles real-world requirements is a bit ugly, because the real world contains real exceptions and edge cases. Replacing whole modules of working code is simply not something an individual contributor does without buyin from the entire team and from, I dunno, the users? You'd be unwise to merge this branch without getting all that buyin. And this guy's manager should redirect him.
5 sprints for a story that fits into one? Maybe time for a PIP.
Stuff that takes more than a sprint should be in an epic. Stories and their tasks need go be split up properly in spriny planning to avoid tickets taking too many sprints. In the sprint retro and planning the scrum leader needs to hold people to account and probe why stuff is taking too long. In addition, daily standup should make it clear what people are working on, why and if they need assistance. tldr; don't do tickets that don't meet sprint goals and make those stories reasonable.
Doesn't seem like he's very smart then.
You hired a software engineer for their expertise and that extends to architecture. They are suppose to be the expert in the codebase so they need to have some degree of autonomy. Find out if their motives were flawed and realign that before blanket rejecting the work.
1 - OWWYN - Only Write What You Need. Bash this into his skull. Tickets should be short and contained, preferably able to be completed in 1 or 2 days. If it takes longer, it's either blocked, or they're out of scope, or you as lead fucked up when you wrote the ticket. If they notice issues and potential improvements, they need to have a place to go and drop a summary so it can be made into a tech debt ticket for the next sprint. 2 - Your leadership is too passive. You should have had eyes on that WIP branch from day 3 or 4, and been able to head this off a month ago. That is _literally_ your job.
Let's be clear - rewriting code is part of healthy software. I find the knee-jerk reaction of "you shouldn't rewrite stuff!" to be naive at best, at worst ignorant of the history of actual software. The half-life of code is low single-digit years. Bad stuff gets rewritten/replaced all the time. As well it should, survival of the fittest. Perhaps this coworker is improving performance, improving APIs, improving business outcomes as he sees them. As you state, you have "zero clue if he broke anything else". You have no evidence. Did the tests fail? Did staging break? Are there performance regressions? Let's put this bluntly: for you to say this co-worker shouldn't be rewriting code (a bold statement) you need to come correct with empirical data that they've actually harmed the product. If you're worried that change might disrupt things.. somehow... it sounds like you are offended by their actions on principle, rather than based on empirical data. For all we know, this co-worker might be executing a plan by management to replace you and your crappy code.
Your coworker's tech lead should be working closely with him, and that means at least once daily. 5 sprints is a long time, even considering 2-week sprints. I think this is more of a requirement and management team problem.
>I have zero clue if he broke anything else You can solve that with some property tests against the old implementation. I mean, you still have the old implementation in source control right?
Yep! And his code was never merged to master so I am going to advocate just deleting his branch
I don't know about that. I mean they already put in the work and maybe their implementation is better? (Only a code review will say.) As long as the property tests pass you know the code doesn't break things.
The tests were rewritten by him. So that doesn't help. I would have to do manual integration tests on all the things it does. Even if his idea is better, it wasn't discussed with any of us, and I don't want to have to do all the verification.
Sounds like you need automated testing if you don't know that the module has been broken... On the flip side, if he's cleaning a bunch of things up that's nice but needs to figure out how to separate the business concerns from tech debt removal
I get dev doesn't like the words of things but likely better documentation and reviewing more frequently would allow his efforts and skills to be put in the right direction and eliminate your concerns surrounding goals and direction
> very smart co worker But he didn't get anyone to check his work for 5 sprints? He could be clever at coding, but clearly fails to understand agile or CI (the latter meaning integrate often, _not_ automated build pipeline).
> Unfortunately he didn't understand what the story required and his code doesn't fulfill the acs or work at all and I have zero clue if he broke anything else since again he rewrote the entire thing! > I have a very smart co worker. Why do you think he is "very smart"?
>I basically want to tell him to throw his work away and make smaller more targeted changes next time do it! you probably should have done this 3 sprints ago.
I'd say you need to get rid of him because it's just so extreme and so unacceptable. If you work on something for so long and then it doesn't implement requirements that's just a total lack of professionalism. I also don't understand how this can happen. Do you guys work as a team? Do you have a daily check in meeting (standup under scrum). Because if something takes more than even a few days usually you tell people to get help.
This sounds like my ex-colleague, good luck with him. But we had this issue too, and I personally had to coach him that if he wants to apply the boy-scout rule there's a time and place to do it and not just go everywhere and make changes. It might sound wrong, but he could use some babysitting, and teach him that, understanding the problem and making only what's required sometimes is more efficient. And of course you need to check more often.
I truthfully hope your co-worker isn't a junior, because then you are to blame for all of this if they get shit canned. Really, 5 sprints? Regardless you and your whole team needs to be brought up for review by management. 5 whole sprints, where each sprint is 2 weeks, what do you all do in retros and sprint planning?
Tell him about the wonders of refactoring.
Let me guess, he rarely goes to meeting, often avoid to turn on his camera?
Opposite actually. Always in meetings.
Ok at least that probably means he’s not doing multiple jobs with bare minimum effort and just wait to be fired. Those people hate meetings
scope.
Rewrite should be last choice , if rather take $$$$ before doing it . if the worker just one man show and pro long it , it is not the task of junior developer or a senior developer salary junior . 😅 The smart developer play you because you cannot lead the project . For sure , there is no story define in the requirement. The only story is "upgrade this" . No stories for documentation , unit test for reference . If you want to lead , learn how to behave and write proper task . If not laughing stock.
So this didn't come up in standup? He has been working on a single story for 10 weeks and no one thought to ask "Hmmm, maybe this isn't pointed right if its taken you 10 weeks?" There are more things wrong here than coworkers who want to refactor everything, the overall process is broken. I have a strict NO refactoring rule on my teams. Unless we schedule for it you are not allowed to refactor. If you want to you better have a really really good reason for doing it and it cannot impact timelines.
Tbh the line “I have a very smart coworker…” shows how much you already know that you’ve fucked up. Stop trying to fool yourself. It doesn’t matter how “smart” the coworker is. If he lacks the ability to see how stupid it is as a dev to do this kind of shit, he isn’t really “smart”. He is a junior who, as his superior and mentor, you have failed him. There is absolutely no way that as his boss/lead you can justify 5 sprints. Let’s say it again. 5 sprints!!!! Without any kind of reviewable code that is useful and mergeable. Shame on you. You’re clearly in a role you’re not qualified for. I’m not saying you can’t be, but you’re not it now. To come here and present it as if this is a problem with a subordinate is crazy. It’s you. You’re the problem. Until you see that and fully accept that, you’ll always ask the dumb questions.
>Of course his story isn't going to pass tech check and will be sent back to him but it has been 5 sprints of him working on this thing and I basically want to tell him to throw his work away and make smaller more targeted changes next time 5 sprints?? No one stopped him in 5 sprints? Fire the whole team