What's an unpopular tech opinion you hold that goes against conventional wisdom?
We want to hear what you think about the tech industry and its t...
For further actions, you may consider blocking this person and/or reporting abuse
I am pretty much against ChatGPT and AI for programming. Not that I don't like the tech behind it because that's very interesting but how the people use it nowadays.
When people learn to program they need to get every sort of skill like syntax, logic, security, workflows and much more. If they use ChatGPT they only get what they reall search for (if they even know what to search for!) and don't learn as much as you would have on the way to the solution by yourself.
It's not for advertising purposes, but I wrote a little blog post about it and why I think it's bad for programmers or learning something in general: aquahub.studio/blog/why-chatgpt-an...
I was also skeptical at first, but I gave it an honest and serious try about a month ago, and now there's no turning back for me anymore.
ChatGPT absolutely replaced Google for me. I have not used Google in a month. Neither have I used StackOverflow for finding solutions for programming related problems.
I get answers to programming problems instantly, and I get a straightforward answer tailored to my exact question, that could take me hours of research the traditional way. ChatGPT goes way beyond the scope of just letting the AI write code for you.
Yes, ChatGPT can often give misleading, even incorrect answers, especially when it generates code. And it will probably confuse the heck out of a generation of junior developers. But for me as a senior dev, it's an amazing tool. It's often able to correct itself when you point out the issues. And even when the code is incorrect, it often contains pointers I would have never found that easily.
I find ChatGPT best and most accurate when I use it on a higher level. It's a great tool for evaluating solution strategies on a higher level. You can have brainstorming sessions with it and discuss possible solution options that touch architectural or design questions for example. It's like "rubber-ducking" a problem except you get smart answers, and it's not just in your head.
Agree, like I said if it only saves you time I think it's a great tool.
You said it will correct itself and yes I know but as a beginner you don't know it did a mistake because you didn't learn all the logic stuff etc. ;)
Amazing post, especially the point about rubber ducking was an eye opener!
I think it gives some people the false notion that they can be developers or experts in any field the easy way, and that is a lie. I am not against AI tools, some people may use them in the wrong way, but in the hands of an expert, it can be a 10x tool, and that is precisely the point. Being able to ship software faster and better, it would never be a bad thing. We just need to learn and evolve with it. This tech is here to stay, and denying it is a mistake.
Hi Christian,
Thank you for sharing your thoughts on AI tools and their impact on the development field. I understand the concerns you raised about some people having false notions that they can become developers or experts in any field easily through the use of AI tools.
While I agree with your points, I would like to add that having false notions doesn't necessarily make someone a liar. Truth can be relative to an individual's perspective and experiences, and it's important to approach discussions with empathy and an open mind.
As moderators of this forum, we strive to create a welcoming and inclusive space where all members can express their opinions and engage in constructive discussions. We appreciate your contribution to this conversation, and we encourage everyone to share their thoughts and ideas respectfully.
Thank you for being a part of this community.
Great comment, and I apologize for the confusion. I believe you may have misunderstood my original statement. I was pointing out that people might mistakenly believe that by using AI tools that provide them with all the answers, they become experts in a specific field. I am suggesting that this belief is misleading because true expertise requires not only knowing the answers but also having the experience and knowledge to ask the right questions. While AI can provide answers, it is individuals with expertise and understanding in a particular area who can make informed decisions and judgments. Encouraging people to rely solely on AI to become experts can mislead them and perpetuate misconceptions.
It depends on how you see the problem, I think. I mean that it has both pros and cons. We can speed up analyzing or get to the main business as soon as possible with chartGPT.
You know, it is true that AI has been boosted and enhanced our world.
Yes, I don't say it's completely bad. I think if it saves you only time then it's worth it.
But if it's disrupting your learning progress by spoon feeding you then I think it's bad.
Actually still waiting for the moment ChatGPT, Copilot or the likes actually save me time.
People have been saying this for years. Compiler have been ruining the young generation's ability to learn to program. Rather than putting time into learn what a register is or how CLD will save your life. People are just describing what they want and the compiler outputs the program for the. Many of these youngsters don't even look at the code generated.
They just playing on their house and imagination, not on the real world!
I wouldn't agree completely on that. It's just that the GPT models are trained on data form 2021. So they don't play in their own house but in the past..
And today's world's changing faster than ever so that's a huge disadvantage.
Yes... what I mean in their house is their comfort zone without knowing the real world.
Oh my bad. Yes I agree.
People are born mature nowaday, and grow like baby.
Gotta disagree here, I find that I learn more. Sometimes I want GPT to generate some implementation in one way, and it suggests a new pattern or library I hadn't ever heard of that I can add to the toolbox. This of course only works if you also prioritize learning what GPT generates, if you just want to copy paste it than yeah, you're not gonna learn anything.
At some point you can really use it to get additinal knowledge (even if it's not as much as you would have learned the tradional way) but only if you got the basic knowledge before.
I don’t know maybe you’re right but I still feel like I learn more than the traditional way (assuming the ‘traditional’ way is docs and tutorials.)
Like the other day I was messing around with a stimulus gem in rails and I was able to pop in to the source and add some print statements to figure stuff out but whenever something didn’t make sense at a glance I could just pop it in chatGPT and have it explained to me, and we’re talking private methods and functions that there aren’t any docs for. Now I feel like I have a way deeper understanding of how the gem works, not just the interface that you’d read about in the docs but the implementation of it too.
You can even ask questions like “why do you think they chose this pattern” and GPT will spit out the pros and cons for the pattern and some alternatives, it’s just a way more natural way of learning IMO (but of course you need to remember LLMs aren’t always 100% accurate, but the same applies to the people making the tutorials)
Edit: after reading more of your comments I agree with you completely. The problem isn’t the tech, but how it’s used, and beginners generally don’t even know enough to ask the right questions so definitely not a substitute for learning the hard way when you’re starting out.
Same here
Symptoms of people concerned with what they will deliver at the end of the day, and not with understanding how they arrived at the result.
I mostly use it to search for very specific errors provided by whatever resource I’m using.
Horizontal scaling is overrated.
The need to set up k8s for every blog post and stuff like that seems to only benefit major cloud providers, and overall, I think it is a cult, not something logical.
A single server can host plenty of workloads.
This narrative that you have to go serverless because it is cheaper and no server to manage is one huge lie. Now you have to manage serverless infrastructure, learn IaC, learn about new types of abstractions, and at the end of that can't sleep well because you might wake up and you are looking at a $30k bill for usage because the app got to the front page of HN or you simply made a mistake and called a serverless function in a loop or something.
We had shared hostings that did the job well. And it was simple.
Now this narrative about the need for horizontal scaling before you even know what app you need to build baked in to people's minds so much that instead of learning actual programming they believe they absolutely need to learn this pile of tools that were made by huge companies for the needs huge companies have.
I still believe in containers, Docker and 12 factor app, but I think that most of the serverless and horizontal talks should not bother most of the programmers and most of the apps.
Example: autoscaling ec2 instances, because you don't want to overprovision compute capacity.
One can get a couple of VPS from other providers, overprovision and still get a lower total cost. Or even a bare metal server.
Bare metal servers is a taboo these days "what if it breaks, or you need to scale, you can't easily scale metal servers".
Most apps, don't have insane hokey stick growth so you can see the need to scaling up long before the moment happens and still pay pennies compared to similar resources in the cloud, so you can freely "orverprovision" 10x and distract your engineering resources with complexity of horizontal scaling.
That came out as a bit of rant, because partially it is, but I really think some things like IaC and serverless stuff are cults and (especially junior people) believe that it is the only way.
We need to teach people to choose the right tool for the job and not put them on the needle of a specific vendor(or set of vendors).
Okay I've added a "like" to this post - and where you said:
"The need to set up k8s for every blog post and stuff like that seems to only benefit major cloud providers ..."
... my reaction was YES - the notion that we all need to become DevOps and Kubernetes experts, and that every dev needs to learn it because yeah, it's important that everyone has the skills to build an auto-scaling application platform from scratch ... is pretty ridiculous in my book :)
But where you lost me is:
"This narrative that you have to go serverless because it is cheaper and no server to manage is one huge lie"
No it's not a lie, it's a new paradigm, and for me it makes much more sense than something like Kubernetes - not for EVERY use case, but for quite a few it does.
And then you lost me again when you said:
"Now you have to manage serverless infrastructure"
No, that's the point - with serverless you don't manage your infrastucture ... you don't rent a VPS, install images, install MySQL/Nginx/whatever ... again, I'm not saying that one needs to choose "serverless" for EVERY project, but I'm convinced it's a game changer.
Full Ack!
It's more difficult to learn to code now than it has ever been.
Too many learning resources (paradox of choice), too many 'experts' with ulterior motives, too much emphasis on results rather than understanding, too many barriers between the learner and actually running some code.
Upgrading to the latest version every time when possible, even when it's just 15 minutes.
Else in the long run you get huge complications and technical debt. Right now in my job I am working on updating our Java 11 stack to Java 17 and oh boy the backlash.
But just for reference, the Java 11 support is going to stop the coming September 2023.
Technical dept can be a killer for projects if you don't watch it.
I don't believe in 'DX'.
Developer experience today basically means adding more and more abstraction to solve problems which shouldn't even exist in the first place, instead of actually learning the fundamentals. * working hard to not list things here *
Don't get me wrong. I like elegant solutions and language which solve certain problems, but it needs to be focused and solve a real problem, and not one existing because we "solved" the last problem.
Copy/Pasting is not a crime.
For 2 reasons:
Refactoring is risky. When you have a code that didn't change in the last 10 years, and won't probably change in the next 10 years, you better let it rest in peace. Just copy the part you need, but don't try to factorize it in common implementation. Note that this is not true if you regularly work in this code. In this case, you better try to improve it.
Copied code will diverge from original. Most of the time, this is an issue because we have 2 part of code that have the same purpose and thus, should stay synchronize. But sometime, you may end up with 2 identical part of code that DON'T have the same purpose. Their resemblance is just a coincidence. In this case, trying to factorize them will generate many special cases and unpredictable behavior.
More details here 😉
kissyagni.wordpress.com/2022/02/17...
We don't need to JS frameworks for everything. Sure, for larger projects which need complex routing and high performance, you'll likely need to use a pre-built solution.
But there's still a strong case for good old vanilla HTML/CSS/JS. The modern landscape of the web lets use build sufficiently complex sites without having to depend on hefty dependencies.
Content needs HTML. HTML needs CSS.
Content doesn't need JavaScript.
C# MVC.
If you have an Order entity with a virtual Icollection OrderLine and OederLine has a virtual Order, when you try to Order.Include(OrderLine) you get a cyclic dependency error. No s*it! It's a primary/foreign key relationship. It's supposed to be cyclic. Now I have to write a heap of boilerplate code. I need an entity model to represent my table. I also need a simpleViewModel for parent and child and a relationship ViewModel for the key relationship and have to access both I have to parentSimpleViewModel.Include(relationshipViewModel).thenInclude(childSimpleVieodel). I could just have called a view in SQL with the FOR JSON modifier and got back an API of the same shape, faster because it's at the DB level and reusable because it doesn't care whether the dB query comes from the API, from a query in Excel or PowerBI/SSRS. If performance is an issue the results can be cached or the JSON generated by another process in the database (e.g. the procedure that adds an order to the system)
Rant Over.
WET isn't always bad; I often wait until I need code for the third time until I abstract it into its own method. For very simple stuff I often don't bother at all with the overhead of an abstraction and just use search-and-replace instead.
Prematurely abstracting code is a sign of someone who lacks the experience to make a good guess for whether or not certain things should be extracted from the start, or should be left until they prove to be generic enough to be extracted.
Integration tests are a scam.
Their complexity grows faster than the codebase they’re testing. They’re sensitive to changes anywhere in the system.
And like for what? If every time I make a change I break an integration test then it provides no value. It’s just testing if a change was made.
Unit tests are great, feature/e2e tests are fine, but integration tests are a waste of effort
Over the years I've develop quite a lot of unpopular opinions, but the most important ones I would say:
More than once, I've re-invented the wheel and benchmarked my solution against the one that everyone else is using, only to find it's an order of magnitude faster for my use-case, if not over all.
DRY (Don't repeat yourself) Does equaly harm and good and i hate Jenkins with a passion.
Monolith can do the work 90% of the time.
A good old template based html web framework can do 90% of the work.
Also, this shouldn't be controversial, but it's worth saying out loud:
Content doesn't need JavaScript. Content needs HTML. And HTML needs CSS Projects that doesn't start with the content are bad projects.
I wrote up mine recently--that languages adding features is often a bad thing and language bloat is a real problem.
Why Every Programming Language Is Terrible
Like what am doing in 7 years as a Software Freestyle Engineer. Am doing a ~~job ~~ fun and client follow my instructions. Cz my canvas and paint is not for everyone, but my art results is available for everyone (and they can buy it from me).
And when we talk about testing; Throw the app on client, then get the feedback!
That's my street world!
Serverless is trash. If a company uses serverless, it says they care about convenience at the cost of user experience.
One belief I hold that goes against the conventional wisdom is my suspicion towards hyper-specialization in the technology industry. As Robert A. Heinlein wisely said, "We are not insects," yet since the 2010s, there's been a growing trend of locking down one's niche to an almost atomic level in the 4th pizza dimension.
In my experience, hyper-specialization can sometimes stifle creativity and innovation. In an industry where technology is evolving at a fast pace, the ability to see the bigger picture and connect the dots 🧀 between different domains 🍕 can be invaluable. Cross-disciplinary knowledge often leads to breakthroughs and solutions that remain elusive when solely focused on a narrow niche. It encourages diversity of thought and the exploration of uncharted territories.
Don't get me wrong; specialization has its merits and its place. There are areas where deep (dish) expertise is absolutely essential—think data science, security, architecture, and more. However, I firmly believe that striking a balance between specialization and having a broader skill set can help us adapt to the ever-changing technology environment and foster a more interconnected approach to problem-solving, always with growth in mind.
Ultimately, it's crucial to find what works best for you and your career goals, but I've learned to be cautious not to pigeonhole myself or others too early or too narrowly in our projects. I have been told I am being to demanding recently. 😋
People go like "tech is an ever-changing industry, you have to always be learning!"... but when I present them to Julia, they will say it's too young, or don't have a mature enough ecosystem, or any other reason, which is very convenient as an argument but not a reasonable excuse - Python in its 12 years wasn't as mature as Julia is now. We should adapt, learn, and help improve innitiatives that aim to build more relevant and easier to maintain applications, such as Julia, or many other languages and frameworks. Some would say this is favoritism but it's just some sense, on my point of view.
A single shared immutable store for UI application state is a mistake.
Keep state local, mutate as you see fit, and communicate with events.
TDD is a religion, you are always told that it has all the benefits and no drawbacks, it solves all testing problems and if you don't use it you are a slow, anti-agile, bug-creating developer