ah1508
Joined 3 years ago
Joined 3 years ago
We tend to think that we make a program, but (writing) the program also makes us what we are. It is what we do that defines what we are. "I think, therefore I am".
I don't see a career path for a prompter. I don't see the benefit for an organization to rely on people who don't understand what they do nor how the programs that keep the organization running works.
That being said, "the man and the machine" can be a powerful combination, like when we drive a motorbike. For me the cooperation with a LLM could work like this: if there is 50 features I write the code for 25 of them and write stubs (classes, methods) for the 25 others, with comments that will be the prompt. The AI audits what I write, gives suggestion, find blind spots and learn best practices from my code. Then I do the same kind of review on the generated code and the AI learns from my review. An AI can even, with luck, suggest a completely new way to solve a problem (see AlphaGo vs Lee Sedol move#37 in game#2) and then I learn something.
Working like that will make me better at reading code (after all Linus spend a lot of time in reading code, it is a good skill to have) while the AI gets better as well. I don't delegate everything and keep practicing, I keep myself up to date, the AI learns from me and I get peer review from the AI. And the codebase does not become a mess (=technical debt) that only another AI can maintain while token prices increases.
For AI it is different, it is just the beginning, leading companies are not even profitable and may never be if the majority hate this technology. VC funding will not last forever and corporate customers will not spend without limit like VC did.
I am not saying that "people are always right", but if an unexpected majority of people hates it, it does not help to keep a business running.
Origins of AI hate:
* "my boss wants me to use AI but he does not understand my job nor how AI works"
* "AI will kill all of us"
* "AI will destroy my job (or my colleague's job if I use AI better than him)".
* I cannot pay my electricity bills because of AI labs.
* ...
See also the mixed feelings about benefits of AI ("harder to justify" according to Uber COO).I cannot remember a technology that arose so much hate, and for good reasons given how it is presented. I am tempted to think that AI hate or reasonable skepticism (vs unreasonable propaganda) can, maybe, reduce funding and will keep specialized AI for real problem solving (producing tons a LOC per day is not one of them, I think).
For most people, GPS did not improve sense of direction, spellchecking did not help to write without making mistake, deepl did not help to be better in foreign languages. But replacing a bicycle by a motorcycle forces to acquire new skills without losing any, and we can find many example of symbiosis between "The man and the machine" (Lindbergh wrote a book named "WE"). AI could be something like that, after all it is human knowledge reachable in a conversational and contextual manner.
So AI can be used to learn: "tell me what's wrong in my code, or if it can be improved". I also tend to think that the more we code, the more we give AI valuable piece of knowledge to learn from, the best code it can produce, the less the produced code seems alien. It can be a win/win, all depend on the mindset. I like to code and even if I am skeptical about many aspects of AI I can share the workload with a robot, as an exercise or if the time or budget is constrained.
But you're right, the goal is not to write test but to ensure delivery of a reliable software. However each software is a prototype, something that has never been made before (unlike a manufactured car or chainsaw) so the customer must be ready to some unexpected behaviors when the software is released.
Since tests are often sloppy or does not cover every edge case, I see a real value for GenAI. It also forces to write good spec: very clear about inputs and the invariants for each use case. I think that AI (especially GenAI) should first be a solution to existing problem, lack of tests and good specs is often one of them.
"I did it like that because it's cleaner" is a non sense. A program must be maintenable, efficient, observable, testable, scalable, performant, readable, secured. Each criteria can be objectively measured in a kind of radar diagram and can be maximized as long as it does not sacrifice another criteria. Form follows function.
Even "simple" (from KISS) is too vague, fortunately in the conference "simple made easy" Rich Hickey defines what is simple: not interleaved. simple comes from sin plex, the opposite of con plex. Not always easy to make something simple.
However I don't see anything wrong with SOLID. Separation of concerns is how a modern society or a football team works, and S brings D because specialization involves good relationships ("no man is an island" wrote John Donne ), and D is strongly related to L. I has no drawbacks.
However I don't separate data from business logic anymore (no data access layer). Business logic applies on data, not on objects that hide data. Translating a ER diagram into anemic classes while the DBA do the same in the DB does not have any value and forces to use obstruction pattern like repository. If entity classes have properties and methods (a Plane class that has a 'takeOff' and 'land' methods for instance) it is different but must most backend I see don't implement entity classes that way. Because their classes represent data, not animated concept. Player class with a shoot method might makes sense for a video game, User class with a addComment method for a CRUD app makes less sense to me.
That's a key point. Keeping knowledge and know how inside the company is strategic. For most people GPS did not result in better sense of direction, spellchecking did not help to write without making mistakes, and delegating translation to deepl does help to be better in a foreign languages. I don't see the gain for an individual, a company, a society if a technology reduces the ability to think, do stuff, understand complex problem, working hard at something. Hiring junior also matters, what is boring for a senior dev is useful for a junior, like the "wax on wax off" in Karatekid. Then when the senior dev retired the junior is not junior anymore and the know how is still here. I want to to transfer my knowledge to a junior, not to anthropic or google or openai.
Ideally, working hand in hand with an AI could be like driving a motorcycle vs riding a bicycle. Both are fine, but you go much faster with a motorcycle and you don't lose any ability. But prompting a motorcycle auto-pilot by voice sound a bit stupid and boring. Insane use of energy rarely comes into the equation, which is a bit weird. Personally it is why I am never tempted to use AI. However I see value in AI for finding weakness in a code (inverse of flattery), writing tests with all the edge cases based on specs since tests are often sloppy, asking a fresh view on a very difficult problem. I'd love to hear about the equivalent of move#32 in game 2 (AlphaGo vs Lee Sedol) in a difficult programming task. But I think that massive delegation of code writing is how you lose the knowledge and the know how: what keeps us sharp.
Final word: I asked once a review to claude, the codes involved a db transaction. Nothing complicated, Claude said everything was fine. However the transaction isolation level was not set (I did it on purpose, like if I did not know about isolation levels). He did not ask me if it was my intention to keep the default level. I would have preferred a challenging feedback: why did you chose the default isolation level ? Is it on purpose ? Do you know that the default depend on the db ? Do you know about isolation ? Tell me about the business use case and I'll explain which one would be the best.
Java is more used than C#, they can wait before delivering a new feature (given their leader position) but cannot deliver a flawed implementation that would stay in the language forever. Glad to have virtual threads and the backward compatibility that comes with it instead a Async version of sync methods + async and await keywords all over the code and Task as a return type in my interfaces methods to allow implementations to do non blocking I/O calls if they need.
I use Java and C# and appreciate them both.
- Junior asks to senior: what did you we use an ORM ?
- senior answers: because it's cleaner.
- junior: ???
I prefer when people are able to define a clear list of objectives: - maintenable;
- performant, scalable;
- efficient;
- resilient;
- observable;
- testable (and tested);
- secured;
- readable for new devs that come on board.
Each criteria balance the others, and the more we add criteria the more it helps to make good choice when we hesitate. It is also meaningful for people outside of the dev team, we can reach an agreement with the customer so he knows what he pays for."maintenable" can be also defined, since a project is mostly in maintenance mode during its lifetime (which means the project is successful, which is good !). The ability to incorporate new features without breaking architecture or even without breaking a single method signature is a good starting point.
Being super careful with abstractions. Here someone wrote something like that: "abstraction often hides how what you want is simple". True, ORM I am looking at you. In most case data should be threaten as first class citizen, it also fosters good collaboration with the DBA.
Thinking beyond "the happy path" without falling in premature optimization is also a challenge. A nice one, once again to it avoids to go head first in implementing a good idea without considering drawbacks.
I also tend to imagine that the one that will work on my code had a very bad day so it must be pleasant to read what I wrote. Comments here and there, locale variable here and there even if they can be avoided, variable naming, etc...
Being selective about frameworks. They are good servant but bad leaders. "Be an engineer, not a frameworker" says an article.
/books/1 could return 200 or 404 depending on the existence of the book#1, here it make sense because if /books/1 does not exist the API must tell it explicitly. However 404 belongs to the 4XX family which means "client error", is it an error to ask for a non existing book ? If you enter in a bookshop and ask for a book they don't have you did not "make a mistake". It's not like if you asked for a chainsaw. But in an API, especially with hypermedia, you are not supposed to request a resource that does not exist (unless the API provides a link to an existing resource that is was deleted before the caller try to reach it).
If you invent a formal language that is easy to read and easy to write, it may look like Python... Then someone will probably write an interpreter.
We have many languages, senior people who know how to use them, who enjoy coding and who don't have a "lack of productivity" problem. I don't feel the need to throw away everything we have to embrace what is supposed to be "the future". And since we need good devs to read and LLM generated code how to remain a good dev if we don't write code anymore ? What's the point of being up to date in language x if we don't write code ? Remaining good at something without doing it is a mystery to me.
This week Porsche showed the mission-S concept, not even a screen in the car. Few features, dedicated to driving and I guess the user manual won't be a 500 pages book. In France Dacia Sandero (low cost car with only basic features) is the most sold in the country. I am not a fan of Steve Jobs and never owned an Apple but, correct me if I am wrong, he wanted a limit set of useful and perfect features for his products.