Having spent most of my career working as a senior contractor, which often meant landing on code bases with 3+ layers of fuckups, I can only imagine how painful it will be to end up having to clean and fix AI generated code, since that doesn’t even have a consistent coding style or pattern of design errors and bugs.
More specifically: the same kind of decision makers are behind both.
To quote the greate Mahatma Gandhi: “Yes”
I see. That does change the idea I had about things a bit.
It’s been a while since I was last hiring.
I wasn’t aware that the problem nowadays in the West (or at least the US) was an excess of people who don’t really have a natural skill for it choosing software development as a career.
That kind of thing was one of the main problems with outsourcing to India maybe a decade ago: the profession was comparatively very well paid for the country so it attracted far too many people without the right skills resulting in a really low average quality of the programmers there - India had really good programmers just like everywhere else but then had a ton of people also working as programmers who should never had gone into it, so the experience of those having to deal with outsourced programming in India usually was pretty bad (I remotelly was a technical lead for a small outsourced team in India from London, and they were really bad whilst, curiously, the good programmers from the Indian Subcontinent I worked with had emigrated from there and were working in London and New York).
I think it’s even worse than just the bar for competency going up: even for a coding wizard going into the career, it’s a lot harder to squeeze through the bottleneck which is getting an entry level position nowadays unless they have some public proof out on the Net of how good they’re at coding (say, commits in open source projects, your own public projects, or even Youtube videos about it).
This is something that will negativelly impact perfectly capable young developers who have an introvert personality type (which are most of them in my experience, even in domains such as Hacking) since some of the upsides of Introversion are a greater capacity for really focusing on on things and for detailed analysis - both things that make for the best programmers - and self publicising isn’t a part of the required skillset for good developers (though sooner or later the best ones will have to learn some “image management” if they end up in the Corporate world)
I’m a bit torn on this since on one side salesmanship being more of a criteria determining one’s chances of getting a break at the start of one’s career as a developer is bad news (good coding and good salesmanship tend to be inverselly correlated) but on the other side a junior developer with some experience actually working with other people on real projects with real users (because they contributed to existing open source projects) has already started learning what we have to teach fresh-out-of-Uni developers to make them professionals.
Sound like a variant of the good old saying “pay peanuts, get monkeys” only using a stick and threats instead of payment.
Mind you, it does sound like the kind of think somebody with his kind of personality - narcissistic shameless and dishonest salesman - would think it’s a great idea.
In my experience working for almost 3 decades in software development, passive-agressive shit from upper management just causes the best people to leave (as they’re the ones who easilly find better jobs) leaving behind mainly a mix of the incompetent and those who never worked anywhere else (who are either already incompetent or will become so, as only ever having worked in just one company is far too narrow professional experience for anything beyond junior/mid level - you need to have seen more than one way of doing things to understand certain higher level concerns and choices in software development).
The one time some manager voiced such an idea, I very overtly in front of everybody offered to make “loop unrolling” software working at the source level (compilers already do it at the Assembly level in some cases for performance) for me and my colleagues to really boost that code line count (while totally screwing maintenability).
Mind you, all devs in that meeting were loudly against measuring performance by code lines, but I like to think that suggestion of mine really hammered down the coup the grace on that “brilliant” idea.
I’ve worked as a freelancer (specifically as a Contractor) in Software Development for over a decade and more often than not I ended up having to work with some existing code base, having to deal with the design choices, coding style and bugs of somebody else, often multiple somebody elses.
There’s nothing quite as “entertaining” as having to deal with 3+ different code and design styles in the same code base because all previous developer thought their own way of doing things was the superior way so just added one more layer of their style (not just coding but, worse, software design) on top of what was already there increasing the mess, rather than work within the existing structure and style and doing some refactoring.
Anyway, in my experience having to read, understand and work with existing code that you yourself did not made is way more time costly and less pleasant than actually doing your stuff from scratch.
Outsourcing killed a lot of the junior and even mid-level career level opportunities in CS and AI seems on track to do the same.
The downside is that going into CS now (and having gone into CS in the last decade or so, especially in English-speaking countries) was basically the career equivalent of just out of the starting line running full speed into a brick wall.
The upside is that for anybody who now is a senior techie things have never been this good because there are significantly fewer people at that level than there is need for such people, since in the last decade or so a lot of people haven’t had the chance to progress in their careers to that point.
Whilst personally this benefits me, I’m totally against this shit and what it has done to the kids entering my career.
I have the impression that most people (or maybe it’s my faith in Humanity that’s at an all time low and it’s really just “some people”) just want pre-chewed explanations given to them rather than spend time and energy figuring things out themselves - basically baby pap as ideas food rather than cooking their own ideas food out of raw ingredients.
Certainly that would help explain the resurgence of Populist sloganeering and continued popularity of Religion (with it’s ever popular simple explanations of “Deity did it” and “it’s the will of Deity”)
Critical thinking, especially Skepticism, does not make for good Consumers or mindless followers of Political Tribes.
Middle and upper management are like little children - they’ll only learn that fire hurts by putting their hand in it.
Good programmers (and I don’t mean just at the coding level) make less bugs exactly because they want to avoid bug fixing as much as possible.
They still have to do debugging - and hence have to be good at it - just less often than if they didn’t invest any time into figuring out ways of working that reduce the rate of bugs in their work (and, again, this is at more levels than just coding).
I think that misconception of “good coders do not produce bugs” in anchored in the totally wrong idea that it’s at all possible to make code without bugs - the way I see it the path to being a “good coder” must go through being good at debugging and just wanting to avoid doing it as much because how how much more time it takes to have to go all the way down to using the debugger to find bugs than doing things like at least some analysis upfront of the program requirements, using proper naming conventions to reduce the likelihood of the kind of bugs that comes from confusing variables and structuring you code so that you don’t get lost or don’t forget things (especially for code you don’t see for months and later come back to having forgotten the logic you were following with it).
I’ve done some programming without proper debuggers (embedded stuff in shitty shit microcontrollers, shader programming) and it’s a total PITA.
The pain in the arse which is debugging is what motivated me to, as my career progressed, improve my coding, improve my software design, improve my systems design, even improved my software development process and standards and eventually that even extended to getting those I worked with to also improving those things as I sometimes ended up having to debug their bugs.
Debugging definitelly makes better techies, IMHO, mainly because of the lengths people will go to in order the avoid having to do it.
It’s pretty much the same as AIs do - copy and past random code from Stackoverflow - but they do it automatically.
In my experience developing In-House custom software it’s more “Managers” and “End-users”: basically the requirements for the software that’s developed are defined by the manager overseeing an area and hence based on their point of view of the business process they oversee, which is often not at all the same point of view as the people working in that process.
I’ve seen again and again software being made exactly to the spec provided by team/area management and then turning out to have lots of problems for the actual users to use.
In my experience the best results come from having the developers talk directly with the end-users, even if the language the devs tend to speak and their preconceptions at first don’t match those of the end-users.
Stuff is done to sell, hence it targets those who make the purchases not the end-users.
You see that a lot in things like children toys, often resulting in the funny result that the kid that gets the toy as a gift ends up having more fun from the box the toy came in than from the toy itself.
Well, that’s the thing, it’s often the case that whilst the client is supposedly doing it for their users, in practice it’s not and is doing it for other reasons.
Mind you, I think that is more common when the software is being developed for a client which is basically a Manager in the same company as the users of the software (for example in In-house Development or Consultancy work developing a solution for a company) were in the absence of the very clear pressure vector which is the customers not buying the product (internal end-users are almost never given a choice to use or not that software, though they can at times informally boycot software they think hinders their work and get the project killed) things are often designed for the Manager rather than for the Users.
(Note that this is not necessarily done in a knowing purposeful way: it’s just that when it’s some external manager providing the requirements to the developers for the software being made for the area that managers overseens - though sometimes it’s even more indirect - things tend to be seen from the perspective of said manager not the end-users, hence designed to match how that manager sees things and thinks things work, which is often different from how the actual users see things. This cartoon perfectly illustrates that IMHO - it looks fine for the “manager” whilst looking quite different for the “end-user”).
Even is B2C you see that: notice the proliferation of things like Microtransactions in Games, which are hardly the kind of thing gamers - who are the end-users of games - wanted to have but which definitelly the management of the big Publishers wanted.
Thanks for that very complete view of things.
Things are quite different since I last was doing hiring, which was pre-COVID.
Yeah, my experience leading a remoted team in India also showed the importance of cultural awareness and good requirements: I ultimately got into the habit of, after the big meeting with the boss were all the work was given to the various teams, get my guys individually on the phone (so that they feared not “losing face”) and carefully coach out of them any questions or doubts since otherwise they wouldn’t voice them and just end up implementing something they misunderstood or which wasn’t explained correctly and indeed they also needed very detailed requirements which was a problem because the senior guys on the other side who ended up having to write said requirements could pretty much have done the job themselves in that time.
This was a big Investment Bank and some top level manager in NY decided to create a division in India to outsource work to, but it definitely didn’t get the cream of the crop over there and the career structuring there was so shit that the few good techies we got would quickly end up as (bad) managers - their pay scales followed the stupid idea that “nobody can be paid more than management” so good mid level techies had to become junior managers to earn more, and they invariably were crap as managers.