30 years later I now understand that most successful projects need people with modest or average technical skills and outstanding communication skills.
It doesn't matter if you have super-genius engineers; if the business people don't really understand the problem that they're trying to solve then you're going to end up with a crap solution (may shiny, fast, and beautiful, but still crap).
* or think at all, in any meaningful way.
A big part of my job in software is having a very sharpened grasp of my ignorance, the ability to weigh a variety of tradeoffs, and the ability to convey my confidence of my abilities and my team's abilities. I'm not sure this is possible for this generation of AI.
Prohibit all physical meetings. Force all communication through mediums that can be pipelined. Feed everything (accounting, contracts, law, etc...). Work will be then to architecture the AI to produce the optimal response.
The first company to figure this out will be too ahead. I don't think anything will be anywhere close to compete including nation states.
Communication might be strictly email in the future. Or something that could be pipelined into the "AI" for context. Video/Calls might make it too at some point. Face to Face meetings strictly prohibited.
We work as translators. We translate intentions into actual descriptions.
A: Eventually we won't need programmers people will just tell the computer what they need and it will generate the code for them.
B: True, there's actually already an industry term for a specification that's detailed enough to generate a working program from.
A: Oh, what is it called?
B: Code.
edit: found it. https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...?
"Okay, I understand what to do when {thing} happens. What do you want done when {not thing} happens?"
"Oh, umm..."
"{Not thing} can happen, right?"
"Oh yeah, all the time."
"So was the plan when it does?"
"I'm not sure..."
It can actually be pretty rewarding to be the person who knows most about the data in the company, while solving logic puzzles during the day.
PS. i do hope most analysts solve more interesting problems than the ones in TFA.
But yes, similar meaning, but replace M with A = Article
I assure you, it wasn't random. It was punitive. ;)
Whoever made the decision very likely wasn't intending to punish the person. It was only the consequence.
And, no, it is very unlikely to be intended as a punishment. More likely he got it because he was too interested in getting good reports. The usual accidental volunteering where if you are too interested in something you end up doing all the hard work.
I wonder what it would look like if we had people across the business working on the same problem together rather than a game of telephone, which is how these data requests end up.
As part of a POC I made, I built a similar bot without recursion for debugging and iterative query building though. It does the following:
- It predicts most probable entities from the question. - Searches AWS Glue Data Catalog for the most probable/useful tables. - It builds an Athena SQL Query from N most useful tables.
It obviously get it catastrophically wrong sometimes, but hell, it was a 3 hour POC. If you can make better indices that map entity->table relationships it should get better at searching tables. Add this kind of recursive/iterative debugging of queries, and you get at least something near a junior-level SQL Analyst.
These kind of bots are analogous to Stable Diffusion, they DO need a good prompter/puppeteer/solution-verifier. Most non-senior Data Analysts also need one anyways.
It’s a neat tool for analysts as a query generator - I would use it in situations where I’m not familiar with the schema, but it would become less useful as I learn.
But hell, as an analyst I would've paid a lot for a tool that searched intelligently through giant datawarehouses (or whatever consultants call them now) and at least gave you probable matches.
Now that same thing exists and you can even finetune its "DSL" towards your own organization.