3 ms·
Aka web front-end developers?
by gaudat 4y ago
Aka web front-end developers?
- gregjor 4y agoAnyone who conflates knowing how to write code with adding business value. Front-end, back-end, doesn’t matter. If you don’t bring more to the table beyond knowing Java or Javascript or HTML at the advanced bootcamp level, skill up.
- wildrhythms 4y agoI feel like backend is more predictable. Known inputs and outputs (think an API). I can get ChatGPT to act like an API with a single query; but actually building a front-end application not so much.
- jmuguy 4y agoWhat do you imagine the backend is doing? Just providing a connection to a database somewhere?
- serpix 4y agoI wonder how you are currently predicting a random api change, login flow change, business reorganisation change, inheriting and integrating a new microservice to the ecosystem of n existing other applications.
- quonn 4y agoBut also only for sort of trivial applications. I run into real problems all the time. It's true that a lot of applications are trivial and often there is no budget for the interesting parts - and that's about to change. So perhaps this development is a good thing.
- whatch 4y agoSome of them, yes. But I believe there are still enough problems in the front-end difficult for LLMs in larger applications. I like the summary regarding front-end here [0]. [0] https://www.joshwcomeau.com/blog/the-end-of-frontend-development/ https://www.joshwcomeau.com/blog/the-end-of-frontend-develop...
- evilduck 4y agoDepends on how you want to show your bias. I've worked with some interesting front end applications that made their moderately complex backends look like trivialities, and I've seen whole teams of mostly useless CRUD API developers who struggle with minimal business logic complexity who are going to be made redundant by one good AI assisted backend dev. Maybe you should introspect a bit.
- gregjor 4y agoThinking in terms of technical specializations and sub-fields illustrates the problem. If you think front-end and back-end describe different species of programmers, or radically different skills in terms of business value, that comes down to the same (I think wrong) idea that Javascript will prove easier to automate than Java because some languages or tools require more skill. The LLMs don't need skill, just training data. Languages and tools and specializations won't matter except that the more widely-used languages will represent a larger training set for the LLMs. The programming industry went through a similar existential crisis back in the 1990s, when pundits predicted outsourcing/offshoring would eliminate our jobs (in the US, anyway). And some jobs did go to Bangalore and Karachi. Programmers didn't get hit as hard as the manufacturing sector, and the work seemed to expand to create more demand. Eventually companies figured out that outsourcing introduces different inefficiencies and problems, often more than it solves. In one of his long articles about LLMs Stephen Wolfram made an interesting point: LLMs apparently show us that we have over-estimated the complexity of human language. Human beings tend to have a high opinion of their own intelligence so that seems very likely. Now that we have software that can produce human-like language we can either tell ourselves the AI overlords have arrived and give up, or we can revise what we think we know about learning human language. Likewise, now we have programs that can write passable code, and here on HN you have to wade through all of the "What do I do now?" posts. Another interpretation: a whole lot of code available to the training models doesn't need much actual intelligence to decipher or write, and we as programmers have solved the same handful of similar problems millions of times. Writing passable code, while not easy to learn, represents the easiest and most replaceable part of developing useful software that has value for the business that paid for it and the customers that use it. And it represents one of the least efficient and least predictable parts of the development process. Imagine framing carpenters just throwing up their hands and fretting about their future when nail guns took over from hammers. The new tool made the carpenters more efficient in some tasks. I expect LLM coding assistants can do the same, but since they can only regurgitate code already written by human programmers they will show apparent skill at solving common problems in common ways, and no skill at anything beyond that. When I switched to full-time freelancing about 15 years ago I stopped using a resume, I stopped highlighting my "technical skills" (e.g. languages, frameworks, tools, etc.). When talking to a prospective client I immediately focus on their business problems rather than whatever things I have used before. They pay me to solve problems with technology. If that means I need to learn something new, I will do that (and fast). I have 40 years experience in the software business, very little actually new or novel happens in the world of programming. If all I could offer to a client came down to "I know Python" I would limit myself, and I would make myself replaceable by a cheaper programmer or an LLM because knowing Python makes very little difference in the big picture -- a necessary but not sufficient skill because I solve business problems, I don't only write Python code. Now that an LLM can write passable Python the people who only offer that skill should worry, and they should expand their skills to include things LLMs can't do and likely won't do anytime soon. That will apply to other fields, not just programmers, but since I know programming I'll stick to what I know.