In other words I feel really bad for bootcamp people right now.
So you built an AI that can parse a perfectly written spec and produce code? The only thing that changed is that the person writing the spec is now a programmer.
So I guess there have been no programmers since the 1950s.
of course it has been, even very recently. where do you think all the demand for bootcamps and bootcamp graduates came from years ago? Why does basically every SWE interview consist of a large % of programming tests?
As for the rest of your post, I didn't say anything like that at all - but it seems like a trivial conclusion to say that "coding" will become less valuable as the interfaces become simpler to it (such as human language interfaces). This is hardly controversial and probably axiomatic.
From managers who know nothing about programming.
Yes, but that is not necessarily the software developer of today.
https://rarehistoricalphotos.com/life-before-autocad-1950-19...
How much of (our, as in, programmers') work is the "writing code" part, vs. all of the other stuff? Build consensus, gather feedback, communicate ideas, resolve ambiguities, make non-zero progress in the absence of clear direction, etc.
In my experience, For a junior/entry level, 80%+
For a (actual, not just title) Sr. dev? Typically <= 20-25%.
10–20 lines of code per day means the “writing code” part is about 2 minutes out of an 8-hour day, if you only count the code that ends up being delivered. maybe 10× that including unit tests, drafts that get replaced, duplicate code that gets refactored away, test code to see what a library will do, etc.
but ai can obviously handle a lot of that stuff too
A standardized way of working is sometimes better because if I have to work with someone- then it helps to be able to work on the same thing together. Tools like Visual Studio, Microsoft Office, even Netbeans or Eclipse allow us to converge on a highly productive but standardize working environment that we can work from.
If I'm running off a highly customized setup, and my partner is also doing the same thing - then I am only functional at my own workstation and nowhere else.
You may have standard vim bindings mostly to manipulate text.
But there are bindings in other IDEs to find next definition/declaration of the function under the cursor, debugging, refactoring, and so on. Within the same IDE, you will find most people don't customize those. At least, in my experience, anyways.
You will still have to read the boilerplate of course.
Basically, take some yaml like:
```
stuff: 1
things.and.stuff: 2
```
If you unmarshal this yaml into a `map[string]int`, the string keys will actually be, "stuff" and "things". Completely dropping the ".and.stuff". Wild. Keep in mind, this is specific to the Viper unmarshaller, the stdlib json or yaml unmarshallers actually handle this fine, I just have other similar complaints about those.
Given this is my main complaint, not performance or general syntax, I do enjoy writing applications in the language though.
What's the language you're using these days that you feel accomplishes the jobs you need it for better than Go? And preferably also has strong concurrency builtins and is typed.
As for specific languages, that's not really my area of expertise. Mojo looks promising in some ways. But it may never be suitable for systems programming.
Anyway, with it in mind that I believe that is not a short term goal: in the short term, I still need to make money. So I write Go for a paycheck. And based on what I believe the tools available around me today are capable of, I think by _today's_ standards, it is nice to work with in a wide variety of tasks.
The way out seems obvious. Either actually stop caring about why people think A sucks or to curtail my curiosity and stop clicking on the "A sucks" articles; and to care more about why people think A is great or at least click on the articles.
llms are better at reading and explaining code than at writing it in my experience
Not necessarily a completely different job, just one where AI won't be able to help all that much without another technological breakthrough, like working with large (several million LOC) codebases.
You’ll still need experts who understand the generated network code, and experts who can untangle the generated code, but not so many.
Code will be a tool used by non-experts; fewer special-case experts will be needed. Where we’ll be when the experts die out, I’m not sure.
The difference between the average bootcamp graduate and the average engineer isn't intelligence, it's knowledge. Once AI makes bootcamp graduates obsolete, I see no reason why engineers in general won't be obsolete too.
Rust implements some algorithms [1] for the same API with the sole purpose to be interchangeable and readily replace one with another. Does a computer know how to do that? I find that not to be the case at the moment.
Algorithms were important in the past, but a lot of programming effort had to be put on mastering every compiler/OS/architecture and their quirks in every case. Now the focus of programmers, will shift more to knowledge about algorithms and data structures.
Not just self-proclaimed programmers either. I've had a chap claim 5+ years of C++ experience working on GE nuclear reactor software, who couldn't explain how C++ memory management works, or delete vs delete[].
So yes, programming interviews it is, unless we get some different form of accreditation like doctors or lawyers.
For what it's worth, I like practical programming problems. The problem comes when the programming interviews don't match the job. Why do I need to write a sorting algorithm in an interview for an SRE position? (I worked at Dropbox for a couple of years, and my interview there was probably the best SRE coding interview I've had - detect duplicate files in a filesystem, with follow-ups about improving performance.)
You can pass job description for Advent of Code task to these curve fitting tools and it will return solution. It is not just about coding. Other technical skills may have become less relevant too.
Coding is a means to an end, and when someone only cares about writing a bitchin' line/method/program struggles to identify and understand (or more importantly communicate) the end, what good is the means?