[Distozion]

I had a similar experience when I got into software. As a junior, more than once I wished to just to quit the field - even after years of CS studies & it being one of the best opportunities one can have in my area.

The draining nature of the "this is shit, we need to do clean code" and "TDD is the way" discussions being constantly repeated day-in day-out, can quickly kill any interest in working on code. It's not that far from being forced to write a book using a 100 most common word list and if you use any word outside of that, you're a shit writer because it will make it harder for others to read, because you used a word that's not in the most common word list...

I'm quite glad that I moved away from that corporate environment into startup space a year later, which showed a whole different perspective. Where code itself is useless and what mattered is if it delivered value. If your hacky solution can deliver value - then you can justify making it better. Otherwise - who cares.

I do think there's way too much attachment to code & its perceived quality in the dev community. On the other hand, if you work in a team where majority of people are well into their careers - there's a lot more nuance when it comes to the extremes such as "TDD all day all night" and "daily pair programming". They are seen as tools to utilise when appropriate, rather than mantras to be repeated mindlessly.

[AnimalMuppet]

It's almost like children versus grown-ups. Children have simplistic, almost magical thinking. Adults know the world is more complicated, and the childrens' simplistic solutions don't actually work very well.

One of the reasons is small sample size. Children don't have the sample size to see why their simplistic solutions don't work. Neither does a programmer with two years of experience.

[jacobyoder]

Colleague of mine working in small company. New 'CTO' hired last year. He's very much of the "everyone's voice deserves to be heard... all input is valid!"

My colleague has 22 years of engineering experience across a wide range of problem spaces and industries and team sizes (large bigco to mom/pop orgs).

Another guy (X) started was a year out of high school.

X insists that 'tech XYZ' is the best. Current tech stack was partially rebuilt by my colleague, but wasn't finished (because... lots of reasons, mostly resourcing).

XYZ is not only not a great fit, but the ecosystem supporting the problem space is small, especially considering what's already in place. Terabytes and years of data need to be migrated (both physically to new data centers and code-wise - new structure handling has to be added to accommodate current and future needs).

In planning meetings, "all voices need to be heard"... so X pushes XYZ a lot. And randomly rebuilds small bits in XYZ. And when it doesn't work - blames everything else (it's the network, it's the supporting libraries, it's ...).

The CTO will not push back. "That sounds great! That sounds like it'll solve all our issues!". There's a criminal deficiency in the understanding of the current tech stack or problems, along with no experience in migrating anything. But any criticism is taken as "we need to be more inclusive and let more people speak up - some of the best ideas can come from people who've not traditionally been heard".

Up to a point, that can make sense. But when do you draw the line? 3 months? 6 months? 18 months? People insisting on promoting child-like understandings of problems and solutions - while not ever delivering anything resembling a working solution - at some point should not be listened to.

Why does my colleague stay? He's only part time right now, and was close to leaving, but there's been some shift to refocus the CTO on something else, which may - over the next month or so - leave the few competent people there alone enough to get things back on track. I think if this was a 'full time' gig for him, he'd have left already.

[Distozion]

One of the startups I worked at had a simple rule - if you wanted to complain about something being bad, you had to come with suggestions how to make it better. And they had to be real, tangible option that could be implemented, not "how about we use technology X".

If you had nothing - you could flag something as an issue - but you were expected to either say how you suggest so solve it or shut up. You did your part of flagging the issues and that was it. It was a startup working with banks & everyone knew there are issues all around, but a lot of them we couldn't solve ourselves, because of the banks being unwilling, regulation being not clear enough if we're allowed to change anything or sometimes both.

If you came with a plan how it can be fixed while minimising the risks associated - no matter if you were junior or senior, at least you'd be listed to. If the ideas are good, the other devs would pitch in to make a realistic implementation plan. Beauty of laws & banking - if something is unclear, no one wants to touch it, so as long as you pass that hurdle - you'd get the go-ahead :D

Yes, quite a few issues ended up being ignored, but at the same time - if no one knows how to fix it, what's the point of draining everyone by continuously complaining how bad it is.

We had relatively few of meta discussion that were not product related - ever since them, I do believe that devs start focusing on code quality and "the right way to do it" only when they lack the power to make any of the product decisions.

[dgb23]

The saddest thing about this story is that X is missing out big time here.

I say that because I started out in a small, very cool agency. However _technical_ leadership and seniority was lacking (they admitted that and made an effort to change that.) I then stagnated on a technical level and had to accumulate that skill set own my own, often on my own time as well.

X being in the presence of a veteran like your colleague should be a golden opportunity for them to learn and grow. Of course open communication and letting everyone voice their opinions has to be part of it. But everything should be weighted, discussed and criticized based in it's objective merits for this approach to make any sense at all.

[DontchaKnowit]

So funny - I was tracking till the end.

I thought you meamt the die hard proponents of these software dev tropes are the childlike ones.

Imo I think that is more apt. I see a lot of resources wasted in the name of conforming to standards when the standard does t really apply to the partocular scenario

[AnimalMuppet]

Either you misunderstood my post, or you are explaining what you think badly, because I think I am in agreement with what you wrote in your last paragraph.