|
Never say never, but it is not going to be so easy as some people would like it to be. And in the end it will be questionable if the whole effort is worth the results. It might be easier to use the original for a while longer than to create a machine in our own image.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I've been hearing similar since the late 80's. Does anyone here remember CASE tools, how they would allow a person to design software specs and them the code would be generated for you? That didn't seem to last too long....
|
|
|
|
|
I'm not holding my breath either. If AI could write code from unambiguous specs, the specs would have to be debugged and fixed if the code didn't do what was actually intended. So in the end, software engineers would simply become "natural language" engineers. Plus ça change...
|
|
|
|
|
Exactly, just another language for those of who design software. One to add to all the other languages learned along the way.
Software development isn't about language specs and such. It is more about having the right mindset, where a person can take a problem and break it down into logical units. Unless you can do that, it doesn't matter what language or tools are used.
I still remember way back to first year of university, sitting in a programing class. A lot of the other students just couldn't get their head around how to design their apps, and ended up switch majors or dropping out....
|
|
|
|
|
 Quote: Does anyone here remember CASE tools, how they would allow a person to design software specs and them the code would be generated for you?
I do: 30 years ago, when I moved to Canada, a friend was raving about Rational Rose and suggested I should look for a different profession because pretty soon all software will be written by tools like that. I was rather sad as I liked coding and I wanted to keep doing that.
In the end I’m glad I didn’t listen to his advice
Mircea
|
|
|
|
|
Thanks for dredging up unpleasant memories. That wasn't even coding with natural language, but coding with drawings. I had to argue against a very similar thing, developed in-house, that was promising the world. Snake oil, but senior management were lapping it up.
|
|
|
|
|
And where's that friend today? Do you ever bring that conversation back up with him?
|
|
|
|
|
We didn't keep in touch. He opened his own consultancy business and did quite well for himself.
Besides, he doesn't have a monopoly on bad ideas or shortsightedness: back in '94-'95 I thought Compuserve was the best network around and the future of Internet lies with them.
Mircea
|
|
|
|
|
It isn't just the business people that see us that way. If you have ever worked with a recruiter, they all seem to see us a commodities, with very little to differentiate any of us. Not to mention that very few of them have any basic understanding of technology, thus are unable to see how best to place us.
I still get job offers to Java development because of a job I had over 10 years ago. Similar for embedded development, even though I haven't done anything like that since the 80's.
Nowadays when I am approached by a recruiter, I tell them I am looking for a management position, or at least as a team lead role. I have yet to be presented any such roles.
|
|
|
|
|
Ugh, recruiters are the worst.
They're also very bad at geography as "a job near you" could just as well be a two hour commute away.
Also, I have my own company, but I still get messages like "you're probably enjoying your current job, but maybe you're looking for a new challenge?"
|
|
|
|
|
If you can create a bot that codes, It can improve infinitely. It can be revolutionary, but fictional.
|
|
|
|
|
And it will demand payment.
|
|
|
|
|
They'll function as middle men: talking with the cloud people about an issue a user is having but can't articulate themselves. The in-house Customer Rep.
As some point, users will simply be told "that is not a service" / option (instead of expecting a software fix).
At one point, no one built LOB apps; they all bought canned systems. Then the PC came out, and everyone started "programming".
We're now back to "packages" (cloud services and "the rep").
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Allow me to take a different approach to an answer. (With the same outcome of course.)
As has been said before, there's a difference between a "handy man" and a "licensed contractor", and they have different duties.
Home owners who hire handy men to do licensed contractors' jobs to save money often wind up with a huge mess which costs even more to remedy.
I am not a Software Engineer, I have never met a Software Engineer.
Very little software is engineered. Airplane flight systems, missile guidance systems, Mars Rover systems, these are engineered.
Point-of-sale systems and Automatic Teller Machine systems, these are engineered.
Operating Systems used to be engineered, I suppose the kernels still are, but the UI less and less.
Web apps, mobile apps, business apps, these are not engineered.
I suppose that this is part of the reason why some people have such a low opinion of "Software Engineers" -- they just don't understand the situation.
There are many hacks who style themselves "Software Engineers" -- these developers should be eliminated from the work force, I wouldn't even buy a cup of coffee from them.
The tools still need to be developed and maintained by Software Engineers.
But the users of the tools are usually not software engineers, they can be software developers like me, people who know what the tool does and how best to use it, how best to apply it to a particular problem set.
So of course the particular details of what the developer does will continue to evolve.
From writing machine code, to assembly code, to C code, to fourth-generation code, etc.
If a business analyst has the ability to specify the details of a program to an nth-generation tool, then that analyst will be a developer.
And it will likely continue to be that the most experienced analyst (with the fewest bugs) will become the go-to developer for the organization (the guru).
Software Engineers will always be required.
"Computer Science" will always evolve.
Bob will continue to bless us with his benevolence.
|
|
|
|
|
|
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
Interesting, I've always used software engineer and developer interchangeably (and I've seen it used that way).
I prefer developer for myself too.
I get what you're saying though, and indeed, I'm not engineering anything.
PIEBALDconsult wrote: And it will likely continue to be that the most experienced analyst (with the fewest bugs)
Not necessarily the most experienced, but the one who just fixes the bug instead of pointing people to some ticketing system, needing approval from a manager, and then gets it into the sprint after the next (because that one's full already), so you'll have your fix in six weeks.
I've been in such an environment and I was the go-to guy.
It's often easier and faster to fix something now (mostly typo's or adding an if-statement or something like that) than to do things the "official" way.
Most of my coworkers weren't that flexible 
Sure, sometimes it's a bigger fix and I'll tell them to do it using the official channels, but then they'll say something like "Sander already knows about it" because they always came to me first.
I can tell you, when the software architect (and management) didn't extend my contract (because they thought I was too much of a cowboy), a lot of people were not happy because at least I actually got some work done 
And yeah, when things get done normally, the number of bugs is absolutely a key metric for becoming the go-to guy 
|
|
|
|
|
Sander Rossel wrote: the number of bugs is absolutely a key metric for becoming the go-to guy
The more expensive the bugs you write are, the more you'll try in the future not to repeat it, and thus you become much more valuable than someone who's yet to write such bugs. It's called experience, and it can't be bought.
|
|
|
|
|
The value of an engineer is directly proportional with the value of the equipment he/she has destroyed.
I know that because I'm a VERY valuable engineer.
Mircea
|
|
|
|
|
Not necessarily, some people are just sloppy or don't care 
I'm ehhh... very experienced
I stopped an entire factory with a SQL update once, most "experiencing" minute of my career 
|
|
|
|
|
On my first job after graduating college, one thing I was asked to develop was a script to stop and restart database...
Yes, I accidentally tested it in production. And it worked.
|
|
|
|
|
Well, that's...good, then? 
|
|
|
|
|
Me, too. 
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Everybody has an overinflated sense of importance.
Most devs I've met throughout in my career at least are rather humble about their abilities. Which is the exact opposite of managers.
|
|
|
|
|
dandy72 wrote: Most devs I've met throughout in my career at least are rather humble
Not all though 
One of the most bloated ego's I've ever met and unfortunately worked with, and hope never to see again, was a (freelance) developer.
It puzzles me how people like him get jobs, friends, a wife and everything.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
