yournameplease

joined 8 months ago

Same thing on my project. Thousands of lines across a few dozen files copied 100+ times. At that point there's almost no going back with everything diverging so long ago.

[–] yournameplease@programming.dev 1 points 2 months ago

It was pretty cool when I tried it on my personal machine. Only annoyance was that it would sometimes generate something I knew was wrong, but my auto-complete muscle memory would use it anyways.

My work machine is pretty underpowered though, so I get suggestions probably less than 1 in 100 times.

[–] yournameplease@programming.dev 1 points 3 months ago

Are you familiar with neocities (geocities revival thing)? It's not anti-scripting but it may scratch your itch.

[–] yournameplease@programming.dev 6 points 5 months ago (1 children)

If your school has Hackathons, try to do those, ideally with friends. The atmosphere is honestly a bit horrible in my opinion and you may get instant imposter syndrome, but it gives you a project to talk about.

[–] yournameplease@programming.dev 2 points 6 months ago

Who’s sped up by your automated tests are your team members and you-in-three-months.

Definitely true. I am very thankful when I fail a test and know I broke something and need to clean up after myself. Also very nice as insurance against our more "chaotic" developer(s).

I've advocated for tests as a team effort. Problem is just that we don't really have any technical leadership, just a hands-off EM and hands-off CTO. Best I get from them is "Yes, you should test your code." ...Doesn't really help when some developers just aren't interested in testing. I am warming another developer on my team up to testing, so at least I may get another developer or two on the testing kick for a bit.

And as for management rating me... I don't really worry too much. As I mentioned, hands off management. Heck, we didn't even get performance reviews last year.

[–] yournameplease@programming.dev 2 points 6 months ago

another team was developing the next best thing under management guidance (so it would become the next monolithic legacy code)

Pretty much what my team is doing. No need to spend time improving the old system when this one will replace it so soon, right? (And no, we will not actually replace anything anytime soon.)

[–] yournameplease@programming.dev 1 points 6 months ago (2 children)

We ~~have~~used to have a scrum master so we're already agile! /s

They want those things, sure, but I think it would take multiple weeks of dedicated work for me to set up tests on our primary system that would cover much of anything. Big investment that might enable faster future development is what I find hard to sell. I am already seen as the "automated testing guy" on my (separate) project, and it doesn't really look like I'm that much faster than anyone else.

What I've been meaning to do is start underloading my own sprint items by a day or two and try to set up some test infrastructure in my spare Fridays to show some practical use. But boy is that a hard thing to actually hold myself to.

[–] yournameplease@programming.dev 1 points 6 months ago (1 children)

especially if the code has been written in a way that makes it difficult to write a robust test.

I definitely deserve a lot of blame for designing my primary project in making hard to test. So, word to the wise (though it doesn't take a genius to figure this out), don't tell two fresh grads and a 1 YoE junior to "break the legacy app into microservices" with minimal oversight. If I did things again, I still think the only sane decision would be to cancel the project as soon as possible. x.x

I actually was using a mock webserver with the expected request/response, which sounds like what you're getting at. Still felt fiddly though and doesn't solve the huge mock data problem which is more an architecture design failing.

I've mostly gotten away from testing huge methods with a seemingly arbitrary numbers in favor of testing small methods with slightly less arbitrary numbers, which feels like a pretty big improvement.

How are you gonna get good at it if you don’t do it! :D

True. :)

[–] yournameplease@programming.dev 5 points 6 months ago

Leadership may be idiots, but devs are mostly just burnt out and recognized that quality isn't a very high priority and know not to take too much pride in the product. I think it's my own problem that I have a hard time separating my pride from my work.

Thanks for the response. It's good to know that my experience here isn't super common.

[–] yournameplease@programming.dev 1 points 6 months ago (1 children)

The combination is bad.

I'm not really sure what there is to do about that, then. My own project is already is about to hit 3 years on something that was intended to be <1 year total, due to constant scope creep. Nothing bad seems to ever come out of the delays though, so I tend to ignore most of the complaints.

If you see it as an argument

I don't really see it as that. "Discussion" is more what I try to do. But you are correct that I don't think I can argue on their terms.

are you sure you understand what they value and prioritize

Probably not exactly, but my point is that the priorities technical leadership says we value (quality, scalability, fast iterations), run counter to what we actually prioritize. I often ask why we prioritize Project X over Project Y and the answer is almost always a variation of:

  • "We can't let IT be the reason the Project X is late."
  • "The business thinks we've been working on Project X a long time (often not true) so we need to show progress."
  • "Project X was promised for Release Z so it needs to get done over anything else."

Which is why I said our priorities are more about appearing busy and important than anything else. (My own project isn't even wanted by most business users. It was spearheaded by the VP of IT as a huge technical modernization effort despite doing almost nothing to improve or get away from the legacy system it is "replacing".) So I think the reason I have such trouble getting buy-in is that better testing runs counter to IT's true priorities, even if it provides business value.

[Trust] might be eroded down due to the consistent failure to meet estimates.

Perhaps. But trust is already pretty darn low for that very reason.

[–] yournameplease@programming.dev 1 points 6 months ago

like they insist on having testing even when the value of it the way it’s being implemented is a little debatable

I started to feel like I was this guy when I asked someone to test their code after multiple sprints of being sent back from QA. Good to hear I'm not the crazy one, I guess.

[–] yournameplease@programming.dev 2 points 6 months ago (4 children)

Perhaps it's just part of being somewhere where tech is seen as a cost center? Technical leadership loves to talk big about how we need to invest in our software and make it more scalable for future growth. But when push comes to shove, they simply say yes to nearly every business request, tell us to fix things later, and we end up making things less scalable and harder to test.

It feels terrible and burns me out, but we never seem to seriously suffer for poor quality, so I thought this could be all in my head. I guess I've just been gaslit by my EM into thinking this lack of testing is a common occurrence.

(A programming lemmy may not be a terribly representative sample, but I don't see anyone here anywhere close to as wild west as my place.)

 

Referring more to smaller places like my own - few hundred employees with ~20 person IT team (~10 developers).

I read enough about testing that it seems industry standard. But whenever I talk to coworkers and my EM, it's generally, "That would be nice, but it's not practical for our size and the business would allow us to slow down for that." We have ~5 manual testers, so things aren't considered "untested", but issues still frequently slip through. It's insurance software so at least bugs aren't killing people, but our quality still freaks me out a bit.

I try to write automated tests for my own code, since it seems valuable, but I avoid it whenever it's not straightforward. I've read books on testing, but they generally feel like either toy examples or far more effort than my company would be willing to spend. Over time I'm wondering if I'm just overly idealistic, and automated testing is more of a FAANG / bigger company thing.

 

I have about 2 YoE, and I'm sure this changes with more experience.

I often hear this idea online that programmers should follow "just-in-time" learning, meaning you should prefer to learn things you don't know while on the job. ( The way some people talk about it, though, it sounds like you shouldn't dare spend a single minute learning anything new outside of your 9-5. )

This seems generally reasonable advice, especially for simpler things that take a few hours like learning a specific language feature, library, or similar. But when I lean too much on this JIT learning, it feels possibly detrimental.

Many times I do something big and new to me, say, deciding how to approach auth, microservice architecture design, automated testing, containerization, etc., I end up making a big decision after a few hours or days of cursory reading on documentation and blogs, only to come to regret it some months later. At that point, maybe I'll slow down, find a book on the subject, read it, and think, "Oh, darn, I wish I knew that N months ago." It certainly feels like spending more time learning upfront could have avoided mistakes due to lack of knowledge. Though there's no way to go back in time and know for sure.

I'm not asking about any area listed in particular. I feel like, for all of those, I've learned more in the time since, and would probably avoid some of my prior mistakes if I did it again. The question is more: How much do you subscribe to this idea of just-in-time learning? And if you do, how do you know when you've learned enough to be confident, or when you need to slow down and learn in more depth?

 

Scene: Surprise meeting with the project owner 0-3 days before the go-live date

"Hey team, the business and I have decided to postpone the project release by n=1-3 months because [they aren't ready for it / it isn't finished /regulatory reasons]. And since we have some extra time now, we can tie up all the loose ends on this project (i.e., 'we've added n+1 months worth of backlog items to the MVP')."

I'm still a greenish dev, so maybe this is normal, but I've had the same story going on for over a year now, and it's really starting to burn me out. In the beginning, I was optimistic. Now I just hope for the project to fail, or me to get off somehow, but this thing just won't die.

Anyone with experience on similar projects able to share words of advice? Do they ever end up working out? Seems there's a death spiral, since we are always rushing to a deadline, forgoing tests and quality but never cleaning up our mess because we're already behind. Yet I somehow feel like I'm the crazy one for thinking this 6-month "quick" side project turned 2+ year half-rewrite will have trouble meeting it's Nth deadline.

view more: next ›