It will make some CS jobs obsolete. Hopefully it will create new ones.
Build full “product skills” and you'll probably be fine
431–440 of 829 posts
Re: Build full “product skills” and you'll probably be fine
#432Looking back we had one CS professor who in 2007 predicted we'd all be jobless in ten years, i.e. 2017. His prediction was based on the trends he was seeing at the time. But it wasn't even AI. Instead he made this prediction because he saw the rise of no-code tools replacing software developers because managers could finally cut out the pesky "translators", i.e. software developers. I said it then and I will say it n…
I love Carmack and this is an interesting summary given his recent pivot into ML.
That said "software is a tool" is a good frame of mind. You shouldn't position yourself as a 'coder' (those are hired en masse from poor countries) but a problem solver who uses tech.
"Ideas guys" and "coders" being seperate only exist, imo, when development is viewed through the junior lens - once you progress you'll end up wearing all the hats from ideation to QA at different points.
Re: Build full “product skills” and you'll probably be fine
#433There's a weird phenomenon I've seen in a few domains of prideful ignorance. Backend engineers who proudly don't know how to write frontend code and vice versa. Professional engineers who refuse to learn how to use modern IDEs and monitoring platforms. People who don't know how to quickly prototype software as if building something without complete rigor is beneath them. People who refuse to learn or work in certain…
What is a modern IDE? It seems like the more recent trend has moved away from bloated IDEs and more to a bring your editor and own plugins environment. From my perspective IDEs lost and things are now closer to how Vim users have been coding for decades.
Re: Build full “product skills” and you'll probably be fine
#434Very misleading title. Implies that Carmack said that, which isn't true.
Agree, that title before wasn’t really great to read, but at least got the point right.
Re: Build full “product skills” and you'll probably be fine
#435What he says here is so true, and something I see many engineers get wrong. Don't glorify and build your career around a single language or methodology. I believe an engineer should learn to build things in the most pragmatic way possible using the best tool for the job. This requires breadth of experience across many areas, and a focus on delivery. The idea of "Java engineer", "Scala engineer", "Golang engineer", et…
I agree with this. When I see ChatGPT output a perfect React program, I don't think "oh shit, it's going to replace me writing React programs." I think "thank goodness I'm not going to need to write that shit anymore." Instead of writing 40 lines of React, I can write two sentences to ChatGPT. It's the same two sentences I would "write" to myself (in my head) before writing the 40 lines of React, but now I save all the hassle of looking up the details or typing out the same drudgery over and over again.
Re: Build full “product skills” and you'll probably be fine
#436That sounds like a good thing. There are many people paid to write software who absolutely cannot write original code and have no idea how things actually work. A lot of that can be, and probably should be, eliminated by AI.
What is considered “original code” ? The code you are writing is probably not original and is built upon layers and layers of abstraction that eventually translated into 0s and 1s . AI or perhaps chatgpt20 could become another such abstraction layer .
Original code refers to the ability to solve a given automation problem without somebody writing that solution for you. That means no frameworks or plugins that solve that for you. The difference is someone who can provide a solution as opposed to copy/paste/configure glue code.
Re: Build full “product skills” and you'll probably be fine
#437Earlier quoted context omitted.
> Since they hire software developers to make the specification more rigid, and the managers don't seem to be getting better at this over time, why would you believe this skill set is going to go away? Some people can take a business goal and figure out how to turn it into a clear spec. Sometimes these people are programmers. However I know programmers who suck at this and I know non-programmers who don't.
This is so true! I see people in this thread talking about the contempt that "idea people" have for programmers/software engineers, but at the same time I have experienced Product Managers (the quintessential idea people?) who were really good at turning their ideas into super detailed specs. As an aside, I'm getting a bit tired from the "programmers vs product/business people" trope. The average software engineer wo…
Many of us were working before product managers became a thing.
When I went to school engineers were trained to work directly with customers and subject matter experts to gather and develop requirements. And that’s what we did when we started working.
I think dividing work into programmer/UX/product manager is an actually huge regression.
Re: Build full “product skills” and you'll probably be fine
#438Looking back we had one CS professor who in 2007 predicted we'd all be jobless in ten years, i.e. 2017. His prediction was based on the trends he was seeing at the time. But it wasn't even AI. Instead he made this prediction because he saw the rise of no-code tools replacing software developers because managers could finally cut out the pesky "translators", i.e. software developers. I said it then and I will say it n…
I too believed that a software engineer's job is to identify and enforce rigorous specification of the abstract high level requirement. And I too was not taking AI advancements seriously but then I took a closer took at what AI tools do today. Here's my concern: 1. AI assistance thrive on structured data 2. Computer programs are some of the most structured data. And it's available abundantly out in the open. 3. Yes,…
> Computer programs are some of the most structured data. And it's available abundantly out in the open.
This is the same Fallacy that we hear since 50 years. All Program requirements are almost the same, just reuse and adapt an existing one. Guess why it has never worked? Because the premise is false. Structured data for X is not optimal for Y (and can be even very wrong).
Apart from the "personal blog software", everything else has various needs of accountability. AI Black box approach is not suitable for any of these so you have to manually verify the code. Veryfing code that you are not familiar with especially in complex interactions is much more difficult that writing it (from this comes the often "rewrite from scratch request", because institutional knowledge has been lost, imagine how much worse it is if this knowledge has never been there in the first place).
Finally and the most important one, all AI models rely on learning, if there is noone to learn from all you get is stagnation. Most of the breakthroughs come from a complete reimagining of the solution space. If the solution space is fixed because "AI has substituted all Engineers" there is no going forward.
Re: Build full “product skills” and you'll probably be fine
#439Earlier quoted context omitted.
You know what a tradesman does today and an AI cannot? Get under the sink, undo that rusted bolt, route that cable in that awkward position and so on.
Too many people make the mistake of thinking there’s an infinite number of sinks to get under.
There is though. In Europe finding a plumber that will take you can have you wait weeks pricelessly because those sinks in existence keep breaking down.
Re: Build full “product skills” and you'll probably be fine
#440There's a weird phenomenon I've seen in a few domains of prideful ignorance. Backend engineers who proudly don't know how to write frontend code and vice versa. Professional engineers who refuse to learn how to use modern IDEs and monitoring platforms. People who don't know how to quickly prototype software as if building something without complete rigor is beneath them. People who refuse to learn or work in certain…
As an engineering manager I’m usually more concerned with those engineers that tend to spend all their time fiddling with IDEs etc, so that they will some day (that never comes) be soooo productive.
If you were my manager I'd quit immediately, and I'm a top performer.