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.)
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:
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.
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.
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.)
Was there any event that prompted more investment into testing? I feel like something catastrophic would need to happen before anyone would consider serious testing investment. In the past (before I joined) there were apparently people who tried to get Selenium suites but nothing ever stuck.
I think nobody sees value in improving something that is more or less "good enough" for so long. In our legacy software, most major development is copy+paste and change things, which I guess reduces the chance of regressions (at the cost of making big changes much, much slower). I think we have close to 100 4k line java files copied from the same original, plus another 20-30 scripts and configs for each...
We are doing a "microservices rewrite" that interfaces with the legacy app (which feels like a death march project by now), and I think it inherited much of the testing difficulties of the old system, in part due to my inexperience when we started. Less code duplication, but now lots of enormous JSONs being thrown all over the network.
I agree that manual testing is not enough, but I can't seem to get much agreement. I think I do get value when I write unit tests, but I feel like I can't point to concrete value because there's not an obvious metric I'm gaining. I like that when I test code, I know that nobody will revert or break that area (unless they remove the tests, I suppose), but our coverage is low enough that I don't trust them to mean the system actually works.
Pretty sure the company was just meaning a LinkedIn clone to "just" be a basic profile upload. Which is probably not that much more than your Twitter clone, just a few extra DB tables.
Still sounds unreasonable for an intern for sure. But I'm sure a few desperate or skilled people would be able to get something meeting the rough requirements.
Full stack is a broad term. As an intern, I changed some font colors and also wrote a couple of backend scripts. That counts as full stack in my book.
Thanks for the response. I agree that the project's big boss has an impressive ability to BS on the greatness of our project, and it may be enough to push the project past the finish line.
It seems you put a lot of weight on the project's "triumph." If the project fizzles out or fails spectacularly, does that not make you more of "the fool who couldn't do it and didn't know when to quit?" I don't think I'd hold it against my coworkers for leaving if they think it would improve their situation. (And doesn't a sound project plan account for the fact that you may lose people every so often?)
Interesting note about small job market though. I only have a ~20 person IT department without much churn so it feels quite small to me still. How do you see this reputation spreading? Just the diaspora of former coworkers is wide enough that most/many companies tend to have someone who knows / has heard of you?
Yes, considering it as a paid education always helps. I don't really think of anyone here as a mentor, so I usually have to study on my own to learn what I need, and I still tend to regret most design decisions I make. And there's just that looming feeling that everything I've worked on is ultimately worthless. But I guess all of this is just part of the software development job, ha.
Interesting that you say jumping damages the personal image, since it seems what most others here advocate. This job gives me good perspective, so I still wouldn't want to go elsewhere without convincing myself that it's a meaningful improvement.
I agree that I tend to enjoy my personal projects far more than anything at my company. My typical problem is that I burn out quickly once I get really into anything long term. And frustratingly, I tend to want to work my own projects most when my work gets most stressful.
I guess it's just hard not to get attached to something you spend so many hours working (and unintentionally thinking) of. But this sounds wise advice.
Sadly not. This post comes after my frustration of this same exact meeting, and now the project is delayed by a nebulous 2-4 (or more?) months. Sounds like I may actually be moving off of it temporarily since it's been pushed so far back, to another, slightly less ambitious project that's getting started. To be determined if I can help this next project go much better.
A big fear I had was that a failed project would reflect poorly on me looking for jobs. But hearing how common dead projects are, I guess it's no surprise that many people go so long not seeing a successful one.
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.