undefined | Better HN

0 pointstitusjohnson1y ago0 comments

I've been on both sides of this table multiple times, as the IC and as the Manager of an eager IC. Here's a list of all the reasons why I as your manager would also flat-out say No to this situation. (These are of course heavily tainted by my own recent experience of trying to coach a mid-level dev through a very similar problem)

- "Pretty much working" means all the fun stuff is done and the actual hard thing is left to wrap up. It's a useless estimate that only accounts for your coding work, which is usually the smallest amount of work performed on an integration feature like this.

- It's a rewrite so we've gotta do a full regression test on every piece of data that thing pulls back. Since it's old functionality it's not fully covered by our automated tests, so this goes to QA. Our QA team is overloaded so this unauthorized, not on the roadmap project now needs to jockey for priority with things that Marketing is literally making artifacts for _today_.

- "It's already built" isn't really a justification for a priority change, so now I'm in the awkward position of changing priorities for a non-roadmap task and justifying this to every single stakeholder who is respecting the process, or telling you it'll be 2 months minimum before QA can even think about it. Either way no one is happy and now I have to worry about you going rogue again and trying to work channels around me to get this thing shipped out of band.

- It's a full rewrite and going through manual QA, so it's nearly guaranteed that critical, but undocumented business rule fixes were missed. Somewhere in that library is a weird function holding up the world, but it was "obviously cruft" and left out. There's a good chance we won't find the issue until it has already polluted a ton of Prod data. That's why I won't let you do Developer QA. You've only been here a year and this service predates you, me, and the rest of the team, we literally have no context.

- If the client finds out we did a full rewrite, they too are going to do a full regression test on their end. Do you know the size of the shitstorm this is going to bring on us? Every single question, problem, feature change, bug, enhancement, communication, _everything_ we went through over the last XX years since we built this integration is going to resurface. I get re-litigate every. single. thing. "Since you're working on our integration can we get XX, XX, and XXXX?" (each is a sprints worth of dev time minimum), "YYY isn't working, did you guys break it again?" (it's always been broken but now someone gets to spend 3 hours in Datadog pulling logs to prove this).

- I've been using the "Rewrite This Library" and "Refactor That Service" projects as leverage to negotiate for more budget to bring on 2 more headcount so that we could actually do those rewrites with proper time and space. You talking about getting 80% done over a weekend has completely undermined the work I've put into this effort, and at the same time didn't remove the Refactor issue from my backlog. Now I will essentially have to shit-talk you in my own 1-on-1s in order to regain lost ground. "sfn42 is a decent developer but he just doesn't have a lot of context to what's happening outside his role. Needs more time in the oven before he gets the bump to Sr. Maybe I can pull him into more planning meetings so he can start growing in this area" -- congrats you just got invited to 6 hours of meetings a month regarding work you won't perform.

- In 6 months when our team is planning out some future work that's just way too much for the headcount & timeline we have, and you bring up "we could really use another Sr. Dev or two, any word on our headcount request?", I might reply politely with a "still no word if we can pull that off this quarter", but internally I'm wondering if the pain of bringing a new dev up to speed is less than the pain of working with you.

- Lastly, the most petulant reason, you were told No last week. I'm sorry you lost a weekend to this, but a No is a No and I need you to understand that. Other things are happening at this company outside the scope of your purview.

Again, this is all drawn from my own experience. I had a mid-level dev show me a huge refactor he started on the weekend. He was convinced it was almost done, "just a few small things left" is an exact quote. However I knew that this part was literally the smallest bit of the effort. I was seeing at least 3 months of work across 4 departments before it would actually be Done, in Production, and working to our satisfaction.

If I had the space I would normally be just fine letting the young fella just experience that pain. Make him do the scheduling, put him on point for everything, and just let him spin on it for a month or so. I did not have that time and space, so instead we spent a few hours white boarding out the rest of what needed to happen, and thankfully he mothballed his project of his own volition.

0 comments

ryandrake1y ago

This reply exudes professionalism and experience in the real world of development where it's not just code leaping from a developer's fingertips into prod. I was going to reply myself, but you covered nearly everything I was going to. Cowboy Coders, please read it carefully and reflect on it seriously.

clcaev1y ago

You could also ask the developer to write comprehensive documentation and test cases, not only for the new code but also for the older code, to ensure the new one can replicate the bugs higher level systems depend upon.

peterkelly1y ago

And that's how you lose good developers

titusjohnsonOP1y ago

In my opinion this is how we shed good coders who are bad developers.

sfn421y ago

You have a lot of good points and some of it may have been applicable in my case.

But this was not complicated. I have underestimated refactors before, this was not one of those times. This was a simple little thing, just getting some data from point A to point B. It would have been easy to verify that the new solution generated the same pages (data in db tables) as the old one.

I didnt undermine anyone. I brought it up in a team meeting, I didn't take it to the department head. Sure I had been told no, but that no was based on the assumption that I was wrong about being able to replace it easily. My weekend coding was simply to prove that it could be done, which I did whether anyone believes me or not.

I really like your last paragraph. You didn't just say no, you walked through it with them and helped them see the problem. I am convinced that the only real reason this did not go through was because nobody else understood the problem. None of our team members had worked with that particular component, everyone were about as new as myself and dismissing my concerns without consideration. Most of all the team lead who hadn't written a line of code in decades and had absolutely no concern for code quality. The review mechanic in that team was push to test, have lead click through website to see if it seems to work, push to prod. Lead did not give a shit what the code was like. The quality of their projects reflected that.

We had over a dozen different apps and pretty much all of them were chock full of bad code written by unsupervised juniors on a tight deadline. All the apps used the same CMS in the backend but nearly all of them had a different frontend approach because they just let people pick whatever - one day you're working in Vue, today it's react, now it's angular, here's a svelte app, this ones just using jQuery and here's one just using vanilla JS. While I was there they let another guy start using a different CMS for another new app, because we didn't have enough problems with all the different js frameworks already, let's start using different backend frameworks too!

Hardly a single test suite anywhere except what I'd made. Everywhere I looked I found bugs and terrible code, every task I got I had to start by figuring out today's flavour of JS framework then try to understand how some junior using this project to pad their CV with the newest JS framework had mangled it together into a somewhat usable website and then how to make the changes I needed to make which 90% of the time was 29 times harder than it should have been because the entire thing was a complete mess hacked together asap and then duct taped, Jerry rigged and beaten with a hammer periodically over it's years of service.

I moved on from that team pretty quickly, and got into a different team much more in tune with my views. About a year later I was talking with two of my old team mates who had been somewhat annoyed with me and all my nagging about testing and code quality back then, at that point they had worked on some of my solutions and felt the benefits of the tests I'd created and the way I actually organized my code to make it easier to understand and work with. It took me by surprise when they flat out, unprompted just told me I was right. When I was working there I had a hard time because everyone disagreed with things I considered basic facts, I started to doubt myself. Luckily the next team was already doing all those things I wanted to do and more. Now I know that good code does exist, the methods I advocate do work, I wasn't just imagining things. That other team was just badly managed.

That's not to say everything I've ever done has been gold, I've made bad decisions and learned from them. But I stand by replacing that old integration library and I still don't believe in this "legacy code" mindset where changing some old pile of crap requires buy-in from multiple different stakeholders and so on.

I might get it when we're talking about large complex, business critical systems that really do require weeks or months of work just to replace a small part. But what I'm talking about is a small website developed in a matter of weeks that's hardly much more than a glorified pdf and where the code behind it has absolutely no business being as complex as it is. Even if my suggested change had broken some requirements they would have been quick to fix because the new code was clear and simple. And the worst case scenario would probably be some messed up formatting in a small article that hardly anyone is going to read anyway.

It should not have been a big deal.

ryandrake1y ago

I guess it also depends on the size of the company and how big of an existing system you are working within. If you are at a decent sized company, then there is no such thing as "not a big deal.' I posted this[1] a while ago in response to a similar complaint about how difficult it is to just wing it in a big company, and I think it's also relevant to this thread.

1: https://news.ycombinator.com/item?id=29644628

j / k navigate · click thread line to collapse

0 pointstitusjohnson1y ago0 comments

0 comments

ryandrake1y ago

clcaev1y ago

peterkelly1y ago

And that's how you lose good developers

titusjohnsonOP1y ago

In my opinion this is how we shed good coders who are bad developers.

sfn421y ago

You have a lot of good points and some of it may have been applicable in my case.

It should not have been a big deal.

ryandrake1y ago

1: https://news.ycombinator.com/item?id=29644628

j / k navigate · click thread line to collapse