Hacker News Reader

This sounds in line with Google creating go: restrict the language features so you can hire mass quantities of programmers and be reasonably sure they won’t go off the rails. It’s fine for what it’s for but doesn’t seem like that should be the goal of most programming projects?

Especially with AI copilots getting better, it feels like we’re headed for a point where you’re either capable of architecting complex systems, or there isn’t much software for you to write: other industries tend to have rote work for beginners while they gain skills, but in software rote work tends to get automated away. AI can help people learn faster, but given what AI has proven good at, I expect more of the gains will go to expert productivity. (or non-programmer domain experts)

I think AI copilots will allow more people to be productive in software and, by so doing, allow vastly more software to be created.

Related to that idea is that, with the right definition (unconventional but not tortured), I think that more software is created in Excel than in python today and a large swath of the people making spreadsheets today for their business will be using AI copilots to make better software 20 years from now.

Totally agree. AI empowers people with existing software expertise, and empowers people with domain knowledge. Both of which have historically been bottlenecked by things AI is now getting good at.

they're called juniors and every other industry has seniors to help guide them and ensure they don't make major mistakes.

Except in our industry. In our industry the juniors often are the ones making the decisions.

That's the problem with software - it's decisions all the way down. Outside of prototyping, there's very little "work" to be done that doesn't contain some kind of systems decision.

this can be limited though. I just went through refactoring a whole set of classes that implement the same interface, but it was not defined as an Interface. now any new class that implements this _must_ meet at least some expectations, enforced by the code.

So in one way, OOP is great for limiting side effects.

Sorry that you've worked for some horrible companies. What you described has not been my experience over the last 10+ years at some rather large and now public tech companies. Part of a Senior's job duties are to mentor Juniors and most job descriptions explicitly list that as an expectation of the Senior role.

I'm unsure as to how that disagrees with what I said.

> they're called juniors and every other industry has seniors to help guide them

> Except in our industry

here's what was actually said without the cherry picking

> Except in our industry. In our industry the juniors OFTEN are

try again.

Often make the decisions. I’m talking about mentoring. Which is what my first comment was specifically mentioning. Which was in response to the parent comment saying mentoring didn’t happen.

the implication of your words here is that you think juniors make decisions while seniors mentor them?

I suppose for some implication is difficult to deal with so let me be explicit.

there often are no seniors. A junior mentoring has another phrase. The blind leading the blind.

Omg, no, that's not what I'm saying.

You said every other industry the seniors guide the jrs, except ours.

I disagreed, and said it's been my experience that seniors are always mentoring jrs.

That's all I was ever trying to reply

> You said every other industry the seniors guide the jrs, except ours.

I didn't say that the first time and I didn't say that the second time when I pointed out you were cherry picking.

At what point do you admit that maybe I know my point better than you and your caricature aint it?

Ok, maybe learn how to say it in ways that don't read as you saying the opposite

> Except in our industry. In our industry the juniors often are the ones making the decisions.

If you're not a native speaker then I understand, otherwise lrn2read.

> they're called juniors and every other industry has seniors to help guide them and ensure they don't make major mistakes.

> Except in our industry. In our industry the juniors often are the ones making the decisions.

"Except in our industry". Said after "every other industry has seniors to help guide them and ensure they don't make major mistakes".

I speak perfect english, dumbass. You need to read your own words because you said seniors mentor jrs. Except in our industry. And then closed with a sentence unrelated to everything else you said, "in our industry the juniors often are the ones making the decisions", which has dick to do with mentoring, the thing everyone else had been talking about up until that last line.

Building construction has been going on for ~thousands of years now. Buildings still fall down. The IT industry is doing remarkably well for its first 70 years.

it's not normal for buildings to fall down, they're usually purposefully pulled down.

In the US buildings have to adhere to legal specifications specifically to ensure that doesn't happen.

> I feel like there is an unfair sentiment of competence elitism in the software engineering world.

And I feel like there are people in software that complain about things like "competence elitism" when other industries encourage doing things right.

Take actual engineers, for example:

https://www.nspe.org/resources/ethics/code-ethics/engineers-...

I'm all for raising the bar of engineering standards though realistically enforcing that would be a significant logistical challenge.

Consider that there are varying levels of competence required for the different problems in software - for instance someone writing code for medical equipment requires a different type and level of expertise than someone writing a website for a small business.

Consider how many YouTubers and blog posts are out there giving bad advice.

Consider how easy it is to get started but also how many niches there are with differing skill sets required by each niche.

Perhaps we could implement a "bar" exam for programmers - however for which niche would it apply? How many different exams would need to be drawn up? By whom and how would this be coordinated internationally?

Does this apply to esoteric segments like Excel or jobs that rely on basic scripting like bash/powershell/SQL/Python?

Would we need to restrict people from giving advice on platforms like YouTube through a licensing system? - much like how it's illegal to give financial advice online without a license in some countries.

It would be nice but I do think that it's extremely ambitious. I struggle to see how it could be implemented inside of a decade long time frame.

Inexperienced engineers aren't the problem. Juniors will submit spaghetti code messes, but those can be cleaned up without too much trouble. The real problem is incompetent people higher up that can make large scale architecture and design decisions. e.g. somewhere I used to work there was a VP that decided to hand roll an ORM instead of just using Django.

> There's also nothing wrong with engineers who program exclusively to collect a paycheck and aren't actually passionate about their work. I believe this is an inevitable side effect of the accessibility of programming today.

I only agree if the person who lacks passion can actually do the job and has experience. The trouble with programming computers is that you cannot get sloppy with the implementation details or design decisions. It is absolutely not a field accessible to people who guess too much and code by coincidence.

Often those details are also overlooked at the project planning level so it's unfair to everyone else who has to pick up their slack. It's already bad enough that the people in charge usually don't understand the project very well.

I'm sorry if it came across this way. It was definitely not intentional! My opinions perfectly match yours, in fact :)

I did try to point out that I don't really blame normal devs but the leadership instead. A fish rots from the head. My writing skills are just not that good (yet) :)

I also used "incompetence" very broadly which was probably a mistake from writing perspective. From bad management decisions all the way to brilliant engineers simply not being familiar with a particular technology/paradigm.

I've seen clients run automated architecture tests with varying degrees of success. These reduce damage done by juniors.

For example tests that ensure that controller actions don't create SQL queries directly but instead always use repositories/services/models (whatever you call data fetching layer).

Another example is a test that ensures that there's no "print" in data fetching layer, only allowing them in HTTP controller actions.

That's the gist of it.

> damage done by juniors

This phrase says it all.

But why doesn't the review process help to improve the quality?

Some clients do use Pull Request reviews.

And to a lesser extent some use Pair Programming.

Automated architecture tests helps to keep things tidy during those rushed moments.

> Automated architecture tests

Is there some good links to know more about it?

Hi zx, I'll link some tools I've seen and/or worked with:

For C#: