Getting junior devs to do this is like pulling teeth. Trying to get a feature stopped after they've built it is soul crushing for them. It's a problem.
At this point I've all but given up beyond minimizing the blast radius in code review.
Being married to your code/output is just another flaw typical for juniors. Put them on features that aren't critical or ensure they are made aware up front that their work may be rejected if it doesn't meet design expectations.
I'm not a junior dev and I still get peeved when my time is wasted. I guess I would only not care if I didn't care about what I was working on, but that's a different kind of existential torment haha.
Beyond opportunity cost, you can think of it as deleterious to your performance. If 10% of your work never gets merged because of shifting priorities, compared with someone else who has miraculously dodged these problems, that's pretty unfair.
10%? Holy shit, I'd say a solid 90% of my output never brought enough value to justify doing it in the first place. Much of it without ever seeing a real user. Software development feels like digging holes and filling them back up again, over and over, to me.
Try to direct your personal energy away from getting your code into the product and towards making the best product possible. Often after building a feature it is obvious that it makes the product worse. I've had many such features cut.
My irritation comes from that decision/realization happening after we already devoted engineering time to something--the most expensive time to reverse yourself.
I've hit this many times over the last 20+ years, and have come to recognize/accept that most people can not really grok something until they can 'use' it in some capacity, often with 'real' data.
Clickable wireframes, design sessions, mockups, etc - they can all help explore ideas before code, and potentially save things. I've had numerous examples where I can identify "this is confusing" or "this doesn't solve the problem, just moves it around a bit" and I'm usually 'outvoted' by others, and do the work. It's usually only after it's in peoples' hands that they identify the rough edges (or more).
100% agree; I'm a huge fan of the design and product process. In particularly I feel like every product team needs a designer--probably not dedicated, but like, dedicated designer hours. It's yet another case of "1 hour (of design) upfront saves 20 engineer hours further on". I've had the (mis?)fortune of working on teams with and without designers and the difference is super obvious, at least to me anyway.
Years ago we had an open session for how to display some unintuitive data on one of our websites, and while few outside the dev team participated, theirs combined with devs' ideas resulted in around 5-10 totally different designs. Mine was one of the first eliminated, most people thought it was weird and confusing. Four months later, after developing and putting the two top-voted ones in front of users and finding they still didn't understand it, our designer came up with basically what I originally suggested, with a few tweaks to make it look nicer. We've kept that version since then.
No code changes should be merged purely because the author got less code merged than someone else on their team. This sounds harsh maybe, but by your reasoning, your feelings could end up being the cause for bugs, poor quality code and/or bad design ending up in a release.
Of course, you and your team should work together to _avoid_ having to reject work! But it can and will happen, it's perfectly normal for mistakes to be made, it's how all humans learn.
Trying to deny that people sometimes fail is foolish. Punishing yourself for making a mistake is on you.
The only unfair thing here is taking others in the team hostage with the idea that you are entitled to getting your work merged regardless of its quality, purely because it would make you peeved, cranky, annoyed! That constitutes toxic behavior. If this is a pattern for you, people will avoid working with you.
Instead: embrace the opportunity to learn. Get feedback, reflect with the team, do better next time. Maybe pair up to refactor your work. Take the positive approach!
I feel like my little comment here became something of a Rorschach test. I'm definitely not saying we should merge bad code to keep merge rates even. All I'm saying is:
- Someone says "build this thing"
- I build "this thing"
- That someone says "just kidding, we're not gonna use it"
- I'm peeved
Someone else in this thread is arguing this is an entitled position, and here you're arguing that... well, I think you're arguing that I think all my code is always amazing and should always be merged.
I'm not! Like I wrote elsewhere I've written some pretty shit code, I've built the wrong thing, and I've built broken things. I'm sure this is true for most SWEs. This isn't the scenario I'm describing.
But I think this discussion has some merit in terms of how we navigate code review. For example, conversely, I've been on the other end of some pretty... bad feedback. The first example that comes to mind is that we had a portal where you could search by text or category, but once you selected a result we wouldn't save your search anywhere (query params, session storage, etc.). Consequently, when you clicked our "back" link, your search would be gone. We YAGNI'd it for a long time, but we accepted a very tight deadline project (COVID/government related) that required a category that needed to be sticky.
I built this using query params, like pretty much every search out there (for good reason). This ended up changing a lot of templates, a couple of front-end React components, and required extra logic in a couple Django controllers. It was a big-ish change, maybe (to my recollection) 300-400 lines across a few stacked PRs--meticulously, for ease of review. All previous tests passed, all the new tests I wrote (typically >= 50% of my PRs were new tests) passed, I even built a punch list of UI tests I ran through (this was going to be a big user-facing feature and I wanted it to be bulletproof). This took I think... 2 days of constant work, so something like ~30 hours.
This wasn't our typical process; we skipped our usual engineering meetings about implementation strategy and what-not. Our team was small--4 people including our CTO--but even so we had a wide diversity of opinion when it came to implementation, architecture, and style, so it kind of ended up being the case that if we wanted anything to get through PR we had to hash it out beforehand. But we literally had 7 days or something to do this, so we just didn't have time.
But, predictably, despite all my tests and punch list, my PRs were rejected as "too much code", and we missed our deadline. We launched without the feature. Our CTO reviewed the vast majority of our PRs, he reviewed these and he was pretty furious about the scope of the changes, blaming me for missing the deadline.
Afterwards, he tried reimplementing it using query params in less code, but failed. He then tried reimplementing it using local storage, which was less code, but had multiple problems: local storage works across tabs which is deeply weird, but even if he switched to session storage, it didn't work in lots of versions of mobile Safari if you're in private browsing mode. I rejected that PR for those reasons, which we disagreed vehemently about. Eventually, a couple months later, we paired on it, and basically reimplemented my work together.
There are obviously a lot of flags in this little story, but I don't think they're wildly out of the ordinary for a startup (if anything, it's way too much process for a 10 person company). My point is that, while I'm sure there are a lot of cases of "I'm God's gift to this company merge all my work never question me" out there, there are also a lot of cases of "no PR is fit to merge the first time" and "I'm a great programmer, you didn't do this the way I would, therefore this isn't good enough" as well.
Hilarious. I wonder what a plumber or carpenter would say if you were to complain to them on how unfair your job is, because 10% of your output doesn't show in the finished product, yet you are still paid for that output. Imagining the reaction to that just made my day.
The enormous silliness of this argument doesn't seem to stop it from popping up all over the place. People's expectations are relative to their environment. The large majority of things you might think to complain about in your life would look hilarious to a caveman or a medieval peasant or even someone from 1980. Similarly, the vast majority of HN users are extremely high-percentile for global wealth and income: this would be a very boring place if people bought in to your paralyzing insistence that you can't ever discuss improvements to something because problems larger than it exist somewhere in the world.
It's a worldview that's so nonsensical that it's its own reductio ad absurdum: If a fast-food worker complained about wanting to be treated with dignity at work, would you similarly scoff at them because coal miners or sweatshop workers don't even get physical safety?
Having high standards is a _good_ thing. It's the hallmark of society's progress. It doesn't preclude being grateful for the privileges you do have, and it's nothing to be ashamed of unless your self-esteem is so low that you think you don't deserve to be treated well.
> People's expectations are relative to their environment. [...] Similarly, the vast majority of HN users are extremely high-percentile for global wealth and income
> Having high standards is a _good_ thing. It's the hallmark of society's progress.
seem to suggest you subscribe to the "trickle-down" ideology. I don't. No, having pockets of "extremely high-percentile" people who are entitled to complain about "unfairness of 10% of their work not being appreciated" is not a hallmark of society progress. It's closer to systemic exploitation. It's a pattern we should know very well from history lessons. No bread? Let them eat cake! Sure. Just brace for the impact when the bubble bursts - there's a sharp blade at the end of this road.
> it's nothing to be ashamed of unless your self-esteem is so low that you think you don't deserve to be treated well.
Because having 100% of someone's work accepted as useful when it's not - for whatever reason - is a basic human right that everyone deserves. That's called "being treated well". I didn't know; I thought not getting 100% sunny days in a year is called "just life", but now I know it's a violation of my rights. How could I be so wrong for so long?
I'm being sarcastic, but you have to accept this comment in its entirety and tell me how happy you are that I wrote it for you. I put work into writing it. I deserve being praised for it, no matter how much you like what I wrote. Right? Please, do treat me well.
> Because having 100% of someone's work accepted as useful when it's not - for whatever reason - is a basic human right that everyone deserves.
Again this wasn't what I was saying. My argument is that engineering time (and time in general) is valuable, and we should be careful how we spend it. In other words: if, over the course of a project, you're wasting a lot of time, that's bad if you care about the project (and you probably should). Maybe you disagree, but I don't think this falls under the "entitled millennial SWE" category, but rather the "we can do better" category.
I'll also, for the sake of discussion here, say I've done some pretty shitty work and have benefited tremendously from code review and general discussions with my colleagues. I'm definitely not someone who thinks they're a "extremely high-percentile" person, probably above average, but definitely not like a Brad Fitzgerald or something.
> I wonder what a plumber or carpenter would say if you were to complain to them on how unfair your job is
I feel like this is a pretty uncharitable caricature of my position. I'm not whining about all my work not getting in. I'm saying, "We're building houses for poor people, I care about this, you had me spend a week on this thing you said was going into one of the houses, you were wrong, I blew a week of work that could've gone to building the houses, and winter is coming". It's not about me personally, it's about me caring about efficiency.
> yet you are still paid for that output
I don't only work to be paid. It's a necessary but not sufficient component. I try to find fulfilling work that I think improves peoples' lives, and I'm fortunate enough to achieve that more often than not. I'm not saying I'm not selfish, just that I'm not entirely selfish, haha.
Hah, an older colleague taught me "it pays the same" as a kind of mantra for dealing with the capriciousness of management. Feels cynical, but I've gotten a lot of use out of it over the years.
It’s especially difficult when they came up with it themselves.
We’re amidst a rewrite and we have an off-shore team involved. They same team that built the original starting 4yrs ago.
One of their team members decides “we should validate the TLD for email addresses entered by the user.” Code is added, a TLD file is added, and in code review I reject the whole concept. Show me the ticket or feature docs, and I’ll argue with the author of those instead.
“We did this in the last app…” Maybe, but we didn’t spec that for this app.
He got his local project lead (non-tech) to write a Jira story for us to “discuss the technical implementation.” Dude, srsly.
Our app is web-first and is used on congested mobile networks (like, hundreds of people all using the same cellular site simultaneously.) A TLD file does not need to be delivered to each of them for validation that’s pointless.
The idea is off the table, code rejected, but the guy spent time doing something no one asked for and had his local team onboard with it.
Is there no planning flow where you work/have worked? I understand giving developers freedom to build, but some sort of oversight by someone with a view of everything that's going on is also necessary.
Typically there are entire planning exercises that happen before stuff even hits a JIRA board.
These are usually conducted by Product Managers, Project Managers, analysts, and often in startups the CEO themselves.
The fact that people are off building features willy nilly sounds like it would contribute to messy code base.
Knowing what's next helps plan the work on the developer side as well which also minimizes the blast radius.
I believe many companies also incentivize this. Not many people get praise, raises and promos by saying no or simplifying things, much less juniors. Once you've built something and put it in your promo doc, no one wants to remove it or say it was the wrong thing to build.
As an example, I did an spike to explore a request from another team. I wrote a short document with my findings and recommended against it due to the cost/benefit analysis. My manager told me not to use this story in my performance review since "we don't want to display failures".
Yes, this is more practical than anyone might imagine.
The guy who just poured the concreted for a foundation, does he care that much that it's torn up or not use? Probably not, even though he's likely skilled and professional.
I know for a fact that a lot of people who build real things take pride in seeing them in use and still around many years later. I think they'd absolutely be demoralized if the typical case saw their work torn up and discarded without ever being used.