nmaley

Guy I knew once was the son of a nuclear physicist. While maybe not quite as smart as his Dad, he was still pretty bright. He started his career as an apprentice plumber. His plumbing career got cut short by a serious back injury so he went back to the books and got himself a degree in mining engineering. Long story short he had a great career in mining and ended up as the wealthy CEO of a listed mining company.

Another guy I know started his career as a cabinetmaker but dropped out of his apprenticeship to go into software development. He didn't have what it takes for that and now he is unemployed.

Moral of these stories? Everything depends on your abilities and interests. Hitting the books and going after a white collar job works well if you're smart. But there a lot of frustrated white collar workers out there doing meaningless work or (with AI at the moment) getting laid off. Many would be better off doing a trade.

I use Claude. It's really good, but you should try to use it as Boris suggests. The other thing I do is give it very careful and precisely worded specs for what you want it to do. I have the habit, born from long experience, of never assuming that junior programmers will know what you want the program to do unless you make it explicit. Claude is the same. LLM code generators are terrific, but they can't second guess unclear communication.

Using carefully written specs, I've found Claude will produce flawless code for quite complex problems. It's magic.

LLMs are parameter based representations of linguistic representations of the world. Relative to robot predictive control problems, they are low dimensional and static. They are batch trained using supervised learning and are not designed to manage real time shifts in the external world or the reward space. They work because they operate in abstract, rule governed spaces like language and mathematics. They are ill suited to predictive control tasks. They are the IBM 360s of AI. Even so, they are astonishing achievements.

LeCun is right to say that continuous self supervised (hierarchical) learning is the next frontier, and that means we need world models. I'm not sure that JEPA is the right tool to get us past that frontier, but at the moment there are not a lot of alternatives on the table.

I've spent a lot of my career doing various types of solution design. One of the insights I gained from thinking a lot about representation, intentionality and the philosophy of language is that the way you represent a problem has a big influence on how easy you will find it to solve the problem. I've found that helps with solution design. Don't just think about the problem. Think about what is the best way to represent the problem.

Majored in Philosophy. Started programming in 1973 on mainframes. Became a full time developer, systems analyst. 72 years old now, with 50 years experience in IT. Co-founded a couple of start ups, made a little bit of money. Went back to corporate life for a while. Ended up as a Program Architect at Salesforce. Resigned to start a company which develops and delivers commercial LLM/RAG solutions. Going reasonably well. Simple principles: keep learning, do what you want to do, not just what the man tells you. I saw a note from another Philosophy grad saying that Philosophy is actually useful in that it gives you a framework and a perspective to look at things a little differently. I agree with that.

I'm in the process of actually building LLM based apps at the moment, and Martin Fowler's comments are on the money. The fact is seemingly insignificant changes to prompts can yield dramatically different outcomes, and the odd new outcomes have all these unpredictable downstream impacts. After working with deterministic systems most of my career it requires a different mindset.

It's also a huge barrier to adoption by mainstream businesses, which are used to working to unambiguous business rules. If it's tricky for us developers it's even more frustrating to end users. Very often they end up just saying, f* it, this is too hard.

I also use LLM's to write code and for that they are a huge productivity boon. Just remember to test! But I'm noticing that use of LLM's in mainstream business applications lags the hype quite a bit. They are touted as panaceas, but like any IT technology they are tricky to implement. People always underestimate the effort necessary to get a real return, even with deterministic apps. With indeterministic apps it's an even bigger problem.

I knew a tech founder once who spent an hour lecturing us (his employees) on business ethics. He'd even written a little red book (like Mao) to codify his thoughts on how we should all behave.

Fast forward a few years and the guy flees the US after being charged with securities fraud. Spends the rest of his life living on his millions in a foreign country with no US extradition treaty.

Look, I love LLMs and even implement them for customers, but I am very sceptical about them 'replacing' ERP and CRP systems. What some AI folks don't seem to understand is that traditional ERP and CRP apps are completely driven by auditable business rules because they have to be. If you're running a company, there's no discretion at all about how money and other assets and liabilities are accounted for. It all has to be strictly according to the rules. This goes for most everything else - management are responsible for the business rules implemented in the system and they need to be precisely spelled out. Sure, AI can and should be used extensively for the human UI piece of it. To simplify getting data into and out of the system for example. But the engine inside and the database are all strictly rule governed and I definitely dont expect that to change anytime soon.

I'm surprised not to see anything about David Cope, who is the real master of AI produced music. Cope works mostly within the classical tradition, using AI to produce work in the style of great composers like Bach, Mozart etc. To my ear, it lacks the brilliance of the originals, but some of it is quite good. Certainly several orders of magnitude better than Suno's AI slop.

Gettier cases tell us something interesting about truth and knowledge. This is that a factual claim should depict the event that was the effective cause of the claim being made. Depiction is a picturing relationship: a correspondence between the words and a possible event (eg a cow in a field). Knowledge is when the depicted event was the effective cause of the belief. Since the paper mache cow was the cause of the belief, not a real cow, our intuitions tell us this is not normal knowledge. Therefore, true statements must have both a causal and depictional relationship with something in the world. Put another way, true statements implicitly describe a part of their own causal history.

I think you are asking the wrong question. Before you decide what to bring in house, you need to have an IT strategy That sets out what components of your desired solution should be built, and what should be bought. You need to have a view about which technologies you will use, and why. What is your end state IT architecture? Have you prioritised your objectives and requirements?

I understand your current systems are holding you back and there may be no appetite to get a bunch of expensive consultants in to answer all these questions. But just hiring a bunch of devs without a plan for what you want them to do is a recipe for disaster.

I know Orwell's work pretty well, and I read that sentence, and thought to myself: "Cant remember where he said anything like that, but what the hell, I haven't read everything Orwell ever wrote". So I just rolled with it.

The cognitive load to fact check everything is too great, so we decide which sources we think are reliable and just accept them. The solution is not to disbelieve everything you are told, but to accept that some of the facts you have not checked might be wrong, and be prepared to re-evaluate when contrary evidence appears.

Excellent. I agree totally. But trying to get adherence to standards in requirements documentation is like trying to nail jelly to the ceiling.

As others have said, rewrite the CV. It's not clear to me who you are and what kind of role would best suit you. Put a summary at the top making clear what you are best at and what kind of role you are looking for. Summarize your skills and achievments. Consider using simple graphics. eg List of tech skills rated with slide bar from expert to familiar understanding.