It is all the magic of early google, and stack overflow... Not as many ads less bullshit.
I have been coding for 25 years. Chat GPT + willing sr engineer means 2 less jr. dev's. I lived through the dot com bust, and now I can do a heroic amount of work with less effort.
This raises two points:
1. It's clear that we have too much grunt work. Im not sure if this is a failure of language design or libraries, but we need to do better at the core.
2. We continue to narrow the path to get experience as an engineer. This is great for companies in the near term (this looming down cycle), but bad for the industry as a whole long term (we dont have a pool of strong jr. engineers).
In Jiro Dreams of Sushi, the new staff starts from cooking rice perfectly first and perfecting roasted seaweed before moving on to preparing an egg sushi and then graduating to fish.
It's not grunt work.
It's how new engineers learn the ropes and gain experience doing low risk work; it's part of the learning process that only feels like grunt work to a senior dev.
I do not think that OP is arguing you should not learn the basics.
Tools like Copilot are very useful because if you need to create a function that takes a FLOAT in addition to the one you just wrote that takes an INT then its right there already. Sometimes I am just trying to bang together something quick for testing just so I can continue on with the actual project.
When I learned to write I did not just paste from Wikipedia into my essays, I would distill words from the articles I read into my own thoughts and writing. These tools are absolutely useful, but it is what you make of it.
> I do not think that OP is arguing you should not learn the basics.
That's not my point, per se.
> It's clear that we have too much grunt work.
What one might see as "grunt work" is what another might see as "learning the ropes".
You can make the case "with ChatGPT, we no longer need to learn the ropes".
But it's really hard to predict how that will affect the next generation of engineers -- I don't even know if "engineers" is the right word -- if they only understand how to ask and not how to construct.
I'd say that my point is that grunt work is very meaningful to someone who is in a different phase of their career. It's not just grunt work, but a pathway to learn.
They’re just higher ropes, instead of cutting your teeth on a Todo app you’ll be writing the apps+web+API equivalent. ie you’ll learn architecture first.
One of my colleagues at my previous lab is porting multiple Matlab toolboxes to Python. These would probably require months for couple of Master's students, but with ChatGPT it is a few weeks work for a postdoc.
Do they have an extensive test suite? I would imagine that it's quite easy to introduce subtle bugs when porting tricky algorithms and other sciency software.
Yes, architecture, medicine and metallurgy have been improved for millenniums. Next to that, IT is a baby that can barely walk. Of course we have too much grunt work.
But also because every time we remove grunt work, the customer expectation increase, the market adapts, and now you have to use new tools that are productive enough to do what the users want with the resource they are willing to pay.
So you don't have to hand write assembly but you do have to have an app that works on 16 screens ratios. You have amazing databases ready to handle your data, but you should update the UI live.
> We continue to narrow the path to get experience as an engineer.
Like in most industries, we are starting to move from "everyone needs to be an experts" to "90% of the daily tasks really just need good technicians". That's fine. That's how it is supposed to be.
At some point only experts could duplicate your house keys. Now you have convenience key stores everywhere.
We are on the right track.
Next stop, the equivalent of residential building codes, but for public facing apps.
Because IT is so new and can be done in your garage, we thought it was special. It was not.
I don’t think the code we consider “grunt work” should necessarily be eliminated. When communicating, it’s useful to have a certain amount of obvious stuff spelled out in order to ground the audience and let them understand the basic context in which the non-obvious stuff is happening.
For example, if you have a configuration, and a particular default would often (say 30% of the time) be overridden, I think it’s typically not a good idea for the default to exist in the first place. Having those defaults will certainly reduce the average config size, but they’ll also create more cognitive load for readers, who now not only don’t know what the default is, but don’t necessarily know that the choice is being made in the first place.
This is one of the things I think is so powerful about AI as a solution. It saves you from the work, but still conveys the basic context to readers without requiring them to understand a bunch of opinions baked into the language or framework.
The same applies to writing prose. When you give a bulleted list to ChatGPT and ask it to turn it into prose, a lot of the work it’s doing is filling in obvious text. But that obvious text is important to communication, and where you have to go and edit that obvious text for correctness will be some of the most important communication in the final product.
> 1. It's clear that we have too much grunt work. Im not sure if this is a failure of language design or libraries, but we need to do better at the core.
We've been iterating over that for decades, there's always one more step of grunt work to remove, one more layer of boilerplate code to move into the compiler (or a code generator), one more deployment task to automate, one more elegant new syntax to add to a language, …
Yeah, and for each piece of boilerplate we remove, we add another few layers of abstraction. At the end of this process we are stuck with crap like YAML and JSON (or, heaven forbid, XML) with the business logic being thinly spread out between logic in shell scripts, shell variables (for CD, for example), in YAML and/or JSON and/or XML within the frameworks in use (spring, mybatis, etc), multiple third-party libraries.
There is no one place where you can find the business logic.
Reminds me of a case where I was trying to help debug some legacy code. I had a simple question, what code gets executed when this method is triggered via the network request. And the final answer that i got from the developer maintaining that code was: I have been working on this for the last 9 months and I have not yet been able to find he entry point from where the requests are handled
I would hope that, in future, some chatgpt like tool would be able to answer basic questions like this and help a new developer start getting productive in much shorter time than now.
Then imagine asking that tool to summarise all the business logic applied in the project or ask questions abou which all sections of the code may need investigation to analyze a bug and come up with a solution.
In the end, I would think of these ai tools as something that can function like another junior or even slightly experienced developer in the team.
It is all the magic of early google, and stack overflow... Not as many ads less bullshit.
I have been coding for 25 years. Chat GPT + willing sr engineer means 2 less jr. dev's. I lived through the dot com bust, and now I can do a heroic amount of work with less effort.
This raises two points:
1. It's clear that we have too much grunt work. Im not sure if this is a failure of language design or libraries, but we need to do better at the core.
2. We continue to narrow the path to get experience as an engineer. This is great for companies in the near term (this looming down cycle), but bad for the industry as a whole long term (we dont have a pool of strong jr. engineers).