Kyle Evans with an excellent reminder that by default, our mind is optimizing for delivery of projects (features). Products also have unique traits that projects don't encapsulate well: SLA, measurement of success, observability, roadmap, clear long-term ownership, and more: "While project thinking focuses on coming up with solutions up-front and then delivering against a schedule, product thinking keeps the focus on the outcome. That involves some level of comfort with uncertainty and learning, which can be pretty hard. But if we want to get to the right outcome, and not just an on-time output, it is really the only way to work."
I'd say so. I've had the pleasure of working with some of the researchers on the applied science team, and they had great depth of knowledge and interest in current problems facing the bio space.
Sure. You've probably seen articles based on genomics (eg. rapid sequencing of undiagnosed rare diseases) and brain scanning work (fruit fly) Googlers have contributed to. Google is not as big in those fields in, say, AI, but still present.
> We are also working hard to broaden the perspective of Responsible AI beyond western contexts.
This really grabbed my attention - I fear big tech is pushing American morals down the throat of the rest of the world.
This is great that they’re noticing this and trying to correct for it!
When you're the 800-pound gorilla in the room, you will always end up in controversies. The fact that the controversy is whether or not Google is demonetizing or making harder to find trans-friendly content in the index (instead of, hypothetically, a world where the controversy was that Google were forwarding the contact information of creators of trans-friendly content to the proper authorities for "reeducation") is indicative (thank God, and may more be like them) of their America-centric morals.
You are absolutely right that for Google to serve everyone, training an AI to do so is a massive challenge. My bet is that they will train several AI and deploy them in broad domains, which is someone equivalent to how they currently operate heuristics that vary from country to country (such as the borders in Maps changing depending on where the request originates). Google seems to tend to like this approach because they think they get the best of both worlds: they satisfy the geocentric power-brokers by saying "See, we have done the right thing by you, when your people make requests they see X," while at the same time knowing that location is a bit of a fantasy online and the sufficiently savvy can get answers from other locations by causing the question to seem to originate from elsewhere in the Internet (i.e. VPN-proxying).
That's not what it said in the title. At the end there are links to the other research they do, and none of that pointed to OS research, as near as I could tell.
I am aware of https://fuchsia.dev/, but it seems to only target handheld devices, which already use the most broken of security models, the dreaded "yes/no" access to location, photos, etc.
I'm looking for a desktop daily driver that supports fine grained capabilities.
You will no longer need to code to be a programmer. I give it 5 years max 10 years. They say software will eat the world. I did not expect software to come after software coders but I guess they are also part of the world. They are the largest expense as well as the fastest growing expense on most of the worlds largest companies balance sheet so replacing them would save billions.
I dont believe this at all. When I think of all the code I work on, most of it is complex logic about what needs to happen in the real world. i.e. if this user has x objects in their cart, and is a rewards member, go get this data if in india else from here. All of that logic has to go somewhere. I do think things like distruted systems, auto scaling, recomndations etc will go away. But the rest is just logic, whether you code it or put it in a config file, it still needs to be done
That's what OP meant. Those logic are defined by business and then translated to implementation logic by dev.
Today there are many situations where one can remove outsourced dev shops, if business themselves can implement the logic that is there in their head. Lowest hanging fruits are perhaps internal IT Tools and workflows.
In my experience business people have a hard time defining logic to the level of granularity that a developer requires.
Even if it's simply a matter of wiring things up, you'd essentially require the developer mindset / training to understand how to wire everything up to accomplish the business objective.
Not to mention knowing exactly what tools to do this in and ensuring any new systems can talk with older ones etc.
Developer jobs aren't going anywhere, it may get quicker to accomplish a task but you're still going to need people who understand the finer details and are able to take a human requirement and break it down and wire things up.
This aligns with my 10 year experience as a consultant working with C suite level executives as well. The people I have worked with are extremely smart and have incredible knowledge about their business. They can think through the happy path quite well. But when it comes to edge cases, error handling, and detailed logic they generally do not have the education/training to think about this properly.
I've converted a few access databases in my day which were surprisingly sophisticated yet the lack of rigor was very transparent. There were good reasons they needed to transition to software written by a developer.
I have a theory of "software literacy" where software is a new form of literacy - and everyone should become literate. All you are saying here is that businesses will be populated by people who can ... read and write. I think there will
come a time when businesses stop outsourcing their reading and writing to external dev shops, but that's not the idea you are thinking about.
IMO your idea is "a dev shop will write lots of paragraphs in such a way they can be fitted together by an illiterate person using config"
I think putting it that way highlights the problems
Edit: another way to look at it is that managers "design" a company with policies and hiring etc. When a company is "software mediated" then the management is now one step removed from reality of the design of the company - the code is the design and the coders are the new managers
Before software you were hiring people to follow your written policies and your occasional orders as policy did not meet reality. Now with software mediated companies, you are hiring people to write the actual policies - and as you do not / cannot be specific enough except in code the actual design is done for the managers - in short management moves to be either the coders or the managers are investors. Either way the "management" work becomes that of coders.
And management this means writing code. Don't write code? not a manager. you can be an investor, a visionary, an accountant and budget holder. All fine. but not actually an executive
I was actually talking about former - stop outsourcing 'reading and writing' to dev shops.
Rules and policies are quite intricately thought through and they get refined as and when 'bugs' or 'holes' are detected (to the detriment of work culture - yet another condition for buying paperclips).
It is often software implementation which does not take care of all ifs and buts, as nobody has patience to write a detailed specs. Most often software tools addresses only frequent cases; when it comes to outliers and exceptions one defaults to 'manual methods' (emails, meetings, face to face talks, etc).
Software implementations can be way behind when trying to keep pace with system intricacies that human minds can conjure up.
But the "intricacies human minds conjure up" can themselves be coded - I mean they are rules that at least two humans have agreed on (at least enough to transact)
The fact that most IT systems are behind is just saying most companies are not software mediated enough, yet. And all the robot automation and so on happening across all companies is a recognition that there needs to be deeper mediation - the implications may not be well thought through but the more a companies processes and decisions are made explicit in software the more change will be forced
As an example just think of volkswagen - someone had to explicitly code up "lie on the exhaust emissions test". if that is not raising / surfacing all explicit rules and assumptions i don't know what is !
It sounds very similar to views expressed throughout history saying why the majority of people could not be taught to read write or add up (variously women, girls, poor people, blacks, slaves, Barbarians etc etc.
And today, all we need for universal programming is Microsoft Excel.
The grandparent has it backwards, if I understand correctly. "Business logic" is to "programming" as "My first spelling book" is to Dostoevsky.
You can write the analog of a memo easily in Excel, or with great effort you could write a sixty page paper, but programmers these days work in teams to produce things that are the writing equivalent of a coherent blend of the Encyclopedia Brittanica, the tax records of 18th-century England, and an epic story 100 times the size of The Lord Of The Rings. And we need bigger systems than that.
That "everyone" (let's say everyone in a white collar job) can use Excel today is true. And yes it is possible to "program" in excel.
But that's in the "small". And I think you are saying that we don't have the programming ecosystem to support large scale development.
I think I agree. But we have to raise the floor of programming literacy a lot beyond "white collar excel".
But having said all that, I am dubious that we lack the principles of coding to be able to enable massive software projects - I think we lack the organisational (incentives / understanding / will) to do so.
We can imagine a mid sized company that is OSS based, avoids proprietary lock in of its data.
I disagree with the systems aspects, and actually think logic is more automated.
I imagine 2 advanced crafts, Design Engineering (UI), and Systems Engineering (distributed, low level, cloud native, and… data).
Everything in between (full stack, APIS, req/res handling, DB integration, data processing, etc) can all be automated efficiently.
Those previous two areas seem to continuously evolve, while APIs and their integration are pretty straight forward and have been for a long time.
I believe AI to be the reason why those two can’t be automated, coincidentally. AI applications require new architectures, AIUX, advanced UI metrics, etc.
Coders aren't coding all the time or even the majority of the time.
It's going to be a while before an AI can take part in a meeting between 2 project managers wrangle out a spec that makes everyone happy and then negotiate with the rest of the team to make the changes necessary.
It's going to be even longer before the AI can figure out why the site is down and bring it back up. And then figure out how to prevent the outage.
Besides that AI isn’t that intelligent yet. Training on all the jQuery code won’t yet give you an AI that can write React.
If AI writes code then now the systems become exponentially more complex exponentially faster . Unless this AI is truly human or super human it won’t keep up. If we have human level AI then coding jobs are the least of our concerns .
> Training on all the jQuery code won’t yet give you an AI that can write React.
If AI genuinely took over coding then languages would become obsolete. The most basic turing complete language, probably some sort of RISC assembly, would be all that would ever be needed.
But when will we get there? A decade ago it seemed like fully autonomous self driving vehicles were just around the corner. Now? Well that corner seems a lot further away than it did then, simply because the problems getting from 99% to 100% are proving quite resilient. Sigmoid curves look exponential on the way up...
The original "no code" dream (ie programs would be written by dragging boxes around in a UI) could have led to this. If instead the future of software becomes large ML models, software engineers will be critical. Feeding the right data, managing configuration and deployments, debugging issues all require software engineering skills.
The obsolescence of programmers has been five years out for how many decades now? Remember when COBOL was going to make it so easy for business analyst and management to work with programs directly? (No, seriously; the fact that it reads almost like English is not an accident.) And sometimes we do make meaningful progress and perhaps AI will be the magical thing that changes everything, but you will forgive me not holding my breath.
Whenever people say stuff like this, I just think - how are all those chat bots working out? How useful do you find Siri?
Honestly, if we can't even get siri to be able to answer simple questions without telling you she'll google it for you, how on earth do you expect developers to be made redundant in 5-10 years?!
Most of the "coding" work I do is not writing code, but instead it's communicating with a client/manager trying to extract the exact requirements for a feature they want implemented. I can't see a computer doing that any time soon and I argue that most developers have the same experience. Having the computer automate the code typing part would be immensely useful, but definetly would not make anyone obsolete.
I generally agree. Maybe not totally, but software developers will have a very different job role in 10 years.
The most obvious is BigQuery, Palantir, Snowflake, etc. So many data pipelines that currently need 10+ teams of engineers to work on will be done through SparkSQL and SparkML by 1 or 2 teams of Data Engineers (i.e. no distributed systems knowledge) instead. It’s not there yet, but dealing (in an asynchronous context) with data at scale is very close to getting commoditized.
Fortunately, UI applications (synchronous, latency sensitive applications, modeling data input from the real world, making things pretty/unique) will likely always need people to write something kinda like code lol. However, I feel like they will likely have classes/experience with HCI/design, product management/MBAs, in the long-long run probably with law/accounting/medicine/architecture/etc.
That said, there is just so much of the real world that needs to be better modeled digitally that everyone that learns coding-like skills will continue to be highly employable. At least, until the singularity. Then all bets are off.
Completely agree that Data Engineering is a bloated skill set. I have devops engineers who can manage/build out complex pipelines and actually prefer they do since we simultaneously manage large scale cloud architectures.
For anything overtly complex (actual data parsing challenges) they usually consult with a data scientist on a team.
I’m constantly reviewing data engineering resume and am wondering “what exactly is this person going to be doing if it isn’t some outdated architecture and o&m work …. Why would we hire this person vs a cloud native software engineer who costs x2 less” etc
somebody needs to understand how it all works though, otherwise we'll end up in some fictional dystopia where nobody understands how their magical technology actually works under the hood.
I can see the tools being made to make lots of automation and connection of tools possible without understanding code, but there will always be people who have to understand it all.
It's strange to see the phrase "technology should be developed with people in mind" coming from Google. Plenty of Responsible AI groups exist. Why can't there be more groups focused on the curtailing of addictive design patterns and similar issues?
The fact that numerous institutions related to AI becoming too powerful exist indicates that there is some part of our capability to progress the state of science that terrifies us. But we don't apply that same type of fear to places like technological addiction that have a significant potential to alter the behavior and development of future human generations.
57 comments
[ 3.7 ms ] story [ 105 ms ] threadKyle Evans with an excellent reminder that by default, our mind is optimizing for delivery of projects (features). Products also have unique traits that projects don't encapsulate well: SLA, measurement of success, observability, roadmap, clear long-term ownership, and more: "While project thinking focuses on coming up with solutions up-front and then delivering against a schedule, product thinking keeps the focus on the outcome. That involves some level of comfort with uncertainty and learning, which can be pretty hard. But if we want to get to the right outcome, and not just an on-time output, it is really the only way to work."
1: https://en.wikipedia.org/wiki/Verily
2: https://en.wikipedia.org/wiki/Calico_(company)
[0] https://alphafold.ebi.ac.uk/
This really grabbed my attention - I fear big tech is pushing American morals down the throat of the rest of the world. This is great that they’re noticing this and trying to correct for it!
That said, with morals being so different from one location on the planet to the other, it's worth wondering how Google will train its "AI."
Will it pick the least restrictive set, the most restrictive set, or some kind of hodge podge? (For varying definitions of "restrictive.")
My money's on a hodge podge that doesn't make anyone happy.
My guess is on whichever makes them the most money; seems a pretty safe bet to me.
You are absolutely right that for Google to serve everyone, training an AI to do so is a massive challenge. My bet is that they will train several AI and deploy them in broad domains, which is someone equivalent to how they currently operate heuristics that vary from country to country (such as the borders in Maps changing depending on where the request originates). Google seems to tend to like this approach because they think they get the best of both worlds: they satisfy the geocentric power-brokers by saying "See, we have done the right thing by you, when your people make requests they see X," while at the same time knowing that location is a bit of a fantasy online and the sufficiently savvy can get answers from other locations by causing the question to seem to originate from elsewhere in the Internet (i.e. VPN-proxying).
I am aware of https://fuchsia.dev/, but it seems to only target handheld devices, which already use the most broken of security models, the dreaded "yes/no" access to location, photos, etc.
I'm looking for a desktop daily driver that supports fine grained capabilities.
That's what OP meant. Those logic are defined by business and then translated to implementation logic by dev.
Today there are many situations where one can remove outsourced dev shops, if business themselves can implement the logic that is there in their head. Lowest hanging fruits are perhaps internal IT Tools and workflows.
In my experience business people have a hard time defining logic to the level of granularity that a developer requires.
Even if it's simply a matter of wiring things up, you'd essentially require the developer mindset / training to understand how to wire everything up to accomplish the business objective.
Not to mention knowing exactly what tools to do this in and ensuring any new systems can talk with older ones etc.
Developer jobs aren't going anywhere, it may get quicker to accomplish a task but you're still going to need people who understand the finer details and are able to take a human requirement and break it down and wire things up.
I've converted a few access databases in my day which were surprisingly sophisticated yet the lack of rigor was very transparent. There were good reasons they needed to transition to software written by a developer.
IMO your idea is "a dev shop will write lots of paragraphs in such a way they can be fitted together by an illiterate person using config"
I think putting it that way highlights the problems
Edit: another way to look at it is that managers "design" a company with policies and hiring etc. When a company is "software mediated" then the management is now one step removed from reality of the design of the company - the code is the design and the coders are the new managers
Before software you were hiring people to follow your written policies and your occasional orders as policy did not meet reality. Now with software mediated companies, you are hiring people to write the actual policies - and as you do not / cannot be specific enough except in code the actual design is done for the managers - in short management moves to be either the coders or the managers are investors. Either way the "management" work becomes that of coders.
And management this means writing code. Don't write code? not a manager. you can be an investor, a visionary, an accountant and budget holder. All fine. but not actually an executive
Rules and policies are quite intricately thought through and they get refined as and when 'bugs' or 'holes' are detected (to the detriment of work culture - yet another condition for buying paperclips).
It is often software implementation which does not take care of all ifs and buts, as nobody has patience to write a detailed specs. Most often software tools addresses only frequent cases; when it comes to outliers and exceptions one defaults to 'manual methods' (emails, meetings, face to face talks, etc).
Software implementations can be way behind when trying to keep pace with system intricacies that human minds can conjure up.
The fact that most IT systems are behind is just saying most companies are not software mediated enough, yet. And all the robot automation and so on happening across all companies is a recognition that there needs to be deeper mediation - the implications may not be well thought through but the more a companies processes and decisions are made explicit in software the more change will be forced
As an example just think of volkswagen - someone had to explicitly code up "lie on the exhaust emissions test". if that is not raising / surfacing all explicit rules and assumptions i don't know what is !
"programming" is to "business logic" like "spelling" is to "writing novels".
You don't get to be a Dostoevsky by being very good at spelling. Being able to tell good stories is much more important than spelling.
You don't get everyone to be a good author by providing them with a tape recorder so they don't have to spell.
Programmers are very good at thinking in logic. Programmming languages are just a detail in this.
Programming is the ability to formulate what the rules should be exactly.
Most (business) people are not able to be that precise no matter the tools you provide them.
It sounds very similar to views expressed throughout history saying why the majority of people could not be taught to read write or add up (variously women, girls, poor people, blacks, slaves, Barbarians etc etc.
Turns out all we needed was schools and paper
The grandparent has it backwards, if I understand correctly. "Business logic" is to "programming" as "My first spelling book" is to Dostoevsky.
You can write the analog of a memo easily in Excel, or with great effort you could write a sixty page paper, but programmers these days work in teams to produce things that are the writing equivalent of a coherent blend of the Encyclopedia Brittanica, the tax records of 18th-century England, and an epic story 100 times the size of The Lord Of The Rings. And we need bigger systems than that.
That "everyone" (let's say everyone in a white collar job) can use Excel today is true. And yes it is possible to "program" in excel.
But that's in the "small". And I think you are saying that we don't have the programming ecosystem to support large scale development.
I think I agree. But we have to raise the floor of programming literacy a lot beyond "white collar excel".
But having said all that, I am dubious that we lack the principles of coding to be able to enable massive software projects - I think we lack the organisational (incentives / understanding / will) to do so.
We can imagine a mid sized company that is OSS based, avoids proprietary lock in of its data.
I imagine 2 advanced crafts, Design Engineering (UI), and Systems Engineering (distributed, low level, cloud native, and… data).
Everything in between (full stack, APIS, req/res handling, DB integration, data processing, etc) can all be automated efficiently.
Those previous two areas seem to continuously evolve, while APIs and their integration are pretty straight forward and have been for a long time.
I believe AI to be the reason why those two can’t be automated, coincidentally. AI applications require new architectures, AIUX, advanced UI metrics, etc.
It's going to be a while before an AI can take part in a meeting between 2 project managers wrangle out a spec that makes everyone happy and then negotiate with the rest of the team to make the changes necessary.
It's going to be even longer before the AI can figure out why the site is down and bring it back up. And then figure out how to prevent the outage.
Besides that AI isn’t that intelligent yet. Training on all the jQuery code won’t yet give you an AI that can write React.
If AI writes code then now the systems become exponentially more complex exponentially faster . Unless this AI is truly human or super human it won’t keep up. If we have human level AI then coding jobs are the least of our concerns .
If AI genuinely took over coding then languages would become obsolete. The most basic turing complete language, probably some sort of RISC assembly, would be all that would ever be needed.
But when will we get there? A decade ago it seemed like fully autonomous self driving vehicles were just around the corner. Now? Well that corner seems a lot further away than it did then, simply because the problems getting from 99% to 100% are proving quite resilient. Sigmoid curves look exponential on the way up...
Whenever people say stuff like this, I just think - how are all those chat bots working out? How useful do you find Siri?
Honestly, if we can't even get siri to be able to answer simple questions without telling you she'll google it for you, how on earth do you expect developers to be made redundant in 5-10 years?!
The most obvious is BigQuery, Palantir, Snowflake, etc. So many data pipelines that currently need 10+ teams of engineers to work on will be done through SparkSQL and SparkML by 1 or 2 teams of Data Engineers (i.e. no distributed systems knowledge) instead. It’s not there yet, but dealing (in an asynchronous context) with data at scale is very close to getting commoditized.
Fortunately, UI applications (synchronous, latency sensitive applications, modeling data input from the real world, making things pretty/unique) will likely always need people to write something kinda like code lol. However, I feel like they will likely have classes/experience with HCI/design, product management/MBAs, in the long-long run probably with law/accounting/medicine/architecture/etc.
That said, there is just so much of the real world that needs to be better modeled digitally that everyone that learns coding-like skills will continue to be highly employable. At least, until the singularity. Then all bets are off.
For anything overtly complex (actual data parsing challenges) they usually consult with a data scientist on a team.
I’m constantly reviewing data engineering resume and am wondering “what exactly is this person going to be doing if it isn’t some outdated architecture and o&m work …. Why would we hire this person vs a cloud native software engineer who costs x2 less” etc
I can see the tools being made to make lots of automation and connection of tools possible without understanding code, but there will always be people who have to understand it all.
The fact that numerous institutions related to AI becoming too powerful exist indicates that there is some part of our capability to progress the state of science that terrifies us. But we don't apply that same type of fear to places like technological addiction that have a significant potential to alter the behavior and development of future human generations.