Some time ago I made a prediction that accessibility is the ultimate API for the UI agents, but unfortunately multimodal capabilities went the other way. But we can still change the course:
This is a great place for people to start caring about accessibility annotations. All serious UI toolkits allow you to tell the computer what's on the screen. This allows things like Windows Automation https://learn.microsoft.com/en-us/windows/win32/winauto/entr... to see a tree of controls with labels and descriptions without any vision/OCR. It can be inspected by apps like FlauiInspect https://github.com/FlaUI/FlaUInspect?tab=readme-ov-file#main... But see how the example shows a statusbar with (Text "UIA3" "")? It could've been (Text "UIA3" "Current automation interface") instead for both a good tooltip and an accessibility label.
Now we can kill two birds with one stone - actually improve the accessibility of everything and make sure custom controls adhere to the framework as well, and provide the same data to the coming automation agents. The text description will be much cheaper than a screenshot to process. Also it will help my work with manually coded app automation, so that's a win-win-win.
As a side effect, it would also solve issues with UI weirdness. Have you ever had windows open something on a screen which is not connected anymore? Or under another window? Or minimised? Screenshots won't give enough information here to progress.
This was posted on HN a while ago and led to some great discussion. Myself and others agreed that this type of stateful visualization was _way_ more effective at conceptualizing how an LLM works than reading code or stepping through a debugger.
I did not realize that learning Fusion 360 was going to be such a huge chapter in my current journey. Looking back, I'm kind of stumped at how I avoided it as long as I did.
I would now put learning CAD in the same category of mandatory life skill as learning to code. The ability to translate what you see in your mind to something that can be repeatably fabricated is an incredible power move, akin to learning how to communicate complex ideas with empathetic language.
My advice is to start by following this tutorial step-by-step. It's a 90 minute video that took me ten days to get through. Step two is to take an existing project and change it in a significant way. Step three is to create something from scratch which solves a problem that you have.
Broadly speaking, there are two capabilities that are going the way of the dodo bird:
1. Software Development
2. Infrastructure Planning
Software Development is going the way of the dodo because the pipeline is drying up for Junior Developers. Now just about any Senior Developer with Copilot can be that fabled 10x developer. A lot of those Senior Developers still have decades of career remaining. Software Development is therefore a dead career to be going into. Anecdote: I have friends who are hiring, each open position is now receiving thousands of applications. We read here on HN about seemingly competent software developers who've spent months if not over a year now looking for a job.
There are two forces causing Infrastructure Planning to go the way of the dodo. One, is Cloud Computing. The other is Infrastructure Planning outsourcers - and the automated tools they're utilizing for infrastructure management. They come in, they setup your data center, and then install tools for you to use to automate the management.
What should you be looking into then?
Architecture. Whether it's Business Architecture, Enterprise Architecture, Enterprise Solutions Architecture, Software Architecture - we need architects. But your game had better far exceed Visio. If you don't know how to manipulate architecture models in tools like Sparx, and you don't know architectural languages such as BPML, SysML, and ArchiMate - then you're getting left behind.
Cyber Security. The laundry list of what you need to know to be competent in this field is too numerous to list here. Added bonus - very few college programs are teaching this stuff so there are very few people in the pipeline and there's a huge demand for their skill. This will likely be a growing field for years to come.
Data Architecture. I see this field as separate and distinct from the architecture I mentioned above. At the end of the day, it's called IT - Information Technology, and data is the new oil. Those people who understand how to manage data flows, data provenance, data storage, data analysis and so forth are in high demand. I look for a lot of this to start getting automated, but I would think it has at least another 10 years of legs under it.
But software development? We can see its end coming. Let me put it this way, there are still going to be software developers but what they do and how they work is going to be fundamentally different from what we've been doing for the past 40 years.
We run coding assistance models on MacBook Pros locally, so here is my experience:
On hardware side I recommend Apple M1 / M2 / M3 with at least 400Gb/s memory bandwidth. For local coding assistance this is perfect for 7B or 33B models.
We also run a Mac Studio with a bigger model (70b), M2 ultra and 192GB ram, as a chat server. It's pretty fast. Here we use Open WebUI as interface.
Software wise Ollama is OK as most IDE plugins can work with it now. I personally don't like the go code they have. Also some key features are missing from it that I would need and those are just never getting done, even as multiple people submitted PRs for some.
LM Studio is better overall, both as server or as chat interface.
I can also recommend CodeGPT plugin for JetBrains products and Continue plugin for VSCode.
As a chat server UI as I mentioned Open WebUI works great, I use it with together ai too as backend.
I have almost 45 years experience in software development, so I can describe the skills that led to my own longevity.
Hardware and the tools and languages available for writing software changed and improved in many ways during my career. My phone has more compute power and memory than the mainframes I worked on in the '70s and '80s. We have more expressive and safer languages, and better tools for writing and testing code. On the other hand I still use, every day, things that date from early in my career: C and C-family languages, relational databases and SQL, Unix in the form of Linux, modern versions of the vi editor. Very little about the practice of software development changed in the last 4.5 decades -- programming books written in the '70s have the same lessons as those published last year, you just have to read PL/I in one and Javascript or Rust in another. Read anything by Brian Kernighan to understand how little software development has actually changed in 40 years, and how programmers continue to repeat the same mistakes, "reinvent the flat tire," as Alan Kay put it.
A big lesson learned way back in the history of software development: Getting the requirements right is the hard part. That hasn't changed, software projects still succeed or fail mostly due to success or failure in the requirements and specification steps. A lot of programmers don't have the experience or interest to learn the business domain or engage with management and users, so they can't write or even correctly interpret requirements. When I started my career I worked with analysts who translated business domain expertise and business requirements into actionable software development plans for the programmers to implement [1] [2]. The analyst role faded away in many companies as software development changed from an ancillary activity (supporting an accounting or logistics department, for example) to a standalone discipline producing products that businesses would adapt to. Today software often dictates requirements rather than the other way around -- if you've ever worked at a company that adopted Salesforce or SAP or Oracle you know what I mean.
Another lesson known as least as far back as Brooks[3] wrote a book about it: People and organizational issues determine the success of software projects to a greater degree (I'd say much greater) than technical skill or choice of language. Learning how to manage teams and projects and work with all of the business stakeholders will prove more durable and valuable than learning the new language of the year.
Writing code got more mechanical over the years, and bugs and performance issues and resource usage became less critical because modern hardware can handle sloppy and bloated code, and modern operating systems and programming languages have a lot more guardrails and fault tolerance. That glosses over a lot of bad code, which in my opinion led to even more sloppy programming. Since LLMs will train mostly on modern code in modern languages I think we can expect more of the same -- workable code that just reiterates what someone else already wrote. That describes what a majority of programmers do now, plugging APIs together, so LLMs can join the team.
To answer your question: I would focus on the fundamentals, which have little to do with programming languages. The fundamental technologies that have stood up for decades with no sign of going away:
- Relational databases and SQL.
- Unix-family operating systems [4].
- C, because it influenced so many later languages, and expresses the essence of programming succinctly.
- Lisp, because it offers a counterpoint to the imperative C style that came to dominate, even if almost no one writes Lisp code today.
- Algorithms and data structures, and algorithmic complexity, which you can learn from '70s-era books by Knuth and Wirth.
I'll add networking and security, things we didn't have or worry much about pre-internet, but today I see a lot of demand for actual experts and few people going that direction, preferring to join the front-end web dev React swarm because of the relatively low bar to entry.
I would also focus on learning business domains and the systems that keep businesses running. I can't get a job today because I know Javascript or Go, but I can get a job because I know a lot about enterprise-level logistics. Outside of the Silicon Valley tech meat grinder you find millions of companies solving business problems they can describe and attach actual costs and risks to, not looking for the next disruption (or grift) with a small chance of success. Businesses don't have requirements like "We need another thousand lines of Javascript by next month." They have requirements like "We need to reduce late deliveries and mistakes by 20%." So learn at least one business domain (best to learn on the job), pay attention to the whole organization and the people, make contacts and friends who aren't fellow Rust geeks, and hone your skills translating business needs into actionable software specifications.
Learn and practice speaking and writing. People who can effectively communicate have a significant advantage over those who can't. [5]
You face a tough job market, especially for people trying to enter the field. Look beyond the big tech companies. You can't ignore AI (what we're calling "AI" this decade) and the possibility it will eventually write entire working software applications, though today that's more hype and VC dreams than reality. But if that does happen I think businesses will still need actual experts who have experience and skills, not just a good memory and algorithm for spewing out code. And I know businesses will need people who can solve business problems rather than just write code.
One of my favorite math/graphics YouTube creators Freya Holmér did an excellent intro to Geometric Algebra not that long ago [1]. If you have any interest in 3d graphics (especially but no limited to splines/Bezier curves) then be sure to check out all of their videos.
I personally have always struggled with linear algebra and I tend to find these Clifford Algebra approaches much more intuitive.
> My only bad experience with prettier, besides the incredible slowness (orders of magnitude slower than ruff)
Ruff is based on the same foundations that Biome (https://biomejs.dev/). Although Biome doesn't support all languages that Prettier supports, you should give a try, it is fast.
The form is
https://www.youtube.com/feeds/videos.xml?channel_id=UC2wdo5v...
where channel_id is the channel hash code which is buried in the source for the "nicely named" channel:
https://www.youtube.com/@CuttingEdgeEngineering
and can be found without source diving via (say) FeedBro (RSS browser extension) "Find Feeds in Current Tab" function.
https://nodetics.com/feedbro/