I don't know, we hired a junior developer and are about to hire another. Not sure it collapsed. I just think it's really hard to get a job across the board right now.
They are getting worse. I don't know why but people keep tweaking and touching them and probably maybe I think it's that they want to make them work for a ton of different models and tools. There's some I use I wish I could just revert to an earlier version.
There will be a need. Don't worry. Most people still haven't figured out how to properly read and interpret instructions. So they build things incorrectly - with or without AI
Seriously. The bar is that low. When people say "AI slop" I just chuckle because it's not "AI" it's everyone. That's the general state of the industry.
So all you have to do is stay engaged, ask questions, and understand the requirements. Know what it is you're building and you'll be fine.
Yes because having a deadline means you aren't set up for quality code...and codebases that are years old are no good. Of course. Sounds like a flavor of the month JavaScript developer. Or the mentality anyway. I know nothing of the author so I don't want to generalize or assume and I definitely agree with a lot of what they are saying. Some very sharp observations.
But companies can't be expected to toss out entire codebases every two years.
A lot of what's mentioned is also true at smaller companies. I see the same exact thing at startups. Now imagine you don't have any programmers who were around for some of the code. No one to ask why or where in the code.
You got 3 or 4 types of programmers that attribute to things in my opinion. At companies big or small.
1. Those who can read through the code and figure things out (or now use the help of AI to do the reading and hunting). These are your A players.
2. Those who try and are cautious but ultimately get tripped up and make mistakes. These are your B players, assuming they can be coached.
The next two types are the EXACT people who end up writing bad code that ends up sticking around for someone in the future. Note that #2 here can write "bad code" but they'll stay around to fix it and will learn and grow (with proper management and support).
3. Those who think they know what they're doing and either move too slow or create bugs. These can be very senior engineers. They're C players, they don't make the cut for long.
4. Those who think they know it all and are very comfortable with changing large areas of code. Who maybe don't tell you they are going to do so (scope creep, inventing problems that didn't exist, determining priorities on their own, etc.). They ship bugs to production and maybe they do go and fix them, great, but sometimes you find people who don't and leave it to others to handle because it's beneath them or something. These people, and they may have decades of experience, are D and F players who need to go asap.
You might see people in group 3 and 4 as "good" or "experienced" because they sound good, interview well, and may indeed know how to write good code - they just don't write good code with others or with an existing code base or just in general because they don't actually WANT to. They don't care.
This brings not only bad code into any company, big or small, it also brings toxicity in. It makes other programmers leave. For example, those that the author talks about as being around longer with limited time. Those people get burned out exactly like the article alludes to. The reason is because of people like 3 and 4.
So I guess that is to say I agree with much of the article, but it's for companies of all sizes and it's not because of deadlines or stock options. It's because that average programmer only sticks around 1-2 years. That's the problem. No one has any commitment. Lots of ego and no team players. That's a lot of what I see unfortunately.
reply