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.
Amazing post, especially the point about rubber ducking was an eye opener!
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. ;)
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.
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.
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...
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.
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.
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.
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
DRY (Don't repeat yourself) Does equaly harm and good and i hate Jenkins with a passion.
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.
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.
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!
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
Monolith can do the work 90% of the time.
A good old template based html web framework can do 90% of the work.
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.
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. π
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