What are your programming hot takes?

Refactoring is something that should be constantly done in a code base, for every story. As soon as people get scared about changing things the codebase is on the road to being legacy.

Only if the code base is well tested.
Edit: always add tests when you change code that doesn’t have tests.
- And also try to make tests that don't have to change if you refactor in future (although there are some exceptions)
Doesn't everybody agree with this? I really never thought of it as a hot take.
- I highly doubt most corps do
- Today I removed code from a codebase that was added in 2021 and never ever used. Sadly, some people are as content to litter in their repo as they are in the woods.
Our company motto is: "leave it cleaner than you found it"
Who is in the wrong? Your manager, for not giving you time to refactor? Or you for giving him the option?
- Why do you need time to refactor? It is just part of the work you need to do and should be accounted for when doing any other work. IMO a big mistake people make is thinking refactoring is some separate thing they need permission to do. You don't, if you need to make a change in some area refactor it first to make it easier to accept your change, then add your change then refactor to clean up. This is not three separate tasks, just three steps in one task. You should be given enough time to do the whole task, not just part of it.
Yes please. Many times when I add a feature I end up refactoring some of the code first to better accommodate it.
We used to call this ‘Code is Cheap’ at my last job - you’re spot on about the value of it
thank_you_michael_scott.gif

Until you know a few very different languages, you don't know what a good language is, so just relax on having opinions about which languages are better. You don't need those opinions. They just get in your way.

Don't even worry about what your first language is. The CS snobs used to say BASIC causes brain damage and that us '80s microcomputer kids were permanently ruined ... but that was wrong. JavaScript is fine, C# is fine ... as long as you don't stop there.

(One of my first programming languages after BASIC was ZZT-OOP, the scripting language for Tim Sweeney's first published game, back when Epic Games was called Potomac Computer Systems. It doesn't have numbers. If you want to count something, you can move objects around on the game board to count it. If ZZT-OOP doesn't cause brain damage, no language will.)

Please don't say the new language you're being asked to learn is "unintuitive". That's just a rude word for "not yet familiar to me". So what if the first language you used required curly braces, and the next one you learn doesn't? So what if type inference means that you don't have to write int on your ints? You'll get used to it.

You learned how to use curly braces, and you'll learn how to use something else too. You're smart. You can cope with indentation rules or significant capitalization or funny punctuation. The idea that some features are "unintuitive" rather than merely temporarily unfamiliar is just getting in your way.

Please don't say the new language you're being asked to learn is "unintuitive". That's just a rude word for "not yet familiar to me"...The idea that some features are "unintuitive" rather than merely temporarily unfamiliar is just getting in your way.
Well i mean... that's kinda what "unintuitive" means. Intuitive, i.e. natural/obvious/without effort. Having to gain familiarity sorta literally means it's not that, thus unintuitive.
I dont disagree with your sentiment, but these people are using the correct term. For example, python len(object) instead of obj.len() trips me up to this day because 99% of the time i think [thing] -> [action], and most language constructs encourage that. If I still regularly type an object name, and then have to scroll the cursor back over and type "len(", i cant possibly be using my intuition. It's not the language's "fault" - because it's not really "wrong" - but it is unintuitive.
- If you only know C and you're looking at Python, the absence of curly braces on code blocks is temporarily unfamiliar to you.
  But if you only know Python and you're looking at C, the fact that indentation doesn't matter is temporarily unfamiliar to you.
  Once you learn the new language, it's not unfamiliar to you anymore.
  "Unintuitive" often suggests that there's something wrong with the language in a global sense, just because it doesn't look like the last one you used — as if the choice to use (or not use) curly braces is natural and anything else is willfully perverse on the part of the language designer.
- No programming language is “natural/obvious/without effort”.
Idk, I don't see a problem with saying a new language is unintuitive. For example, in js I still consider the horrible type coercion and the "fix" with the triple-equals very unintuitive indeed. On the flip side, when learning C# I found the multiple ways of making comparisons to be pretty intuitive, and not footguns.
Please don't say the new language you're being asked to learn is "unintuitive". That's just a rude word for "not yet familiar to me".
Yeah. I've written in six or so different languages and am using Go now for the first time. Even then, I'm trying to be optimistic and acknowledge things are just different or annoying for me. It doesn't mean anything is wrong with the language.
ZZT-OOP is fun to work with though, definitely not meant for doing anything more complex than light gameplay, and yet people have done ridiculous things with it.
Though I personally did most of my coding in that vein in MegaZeux with their Robotic language, which is basically ZZT-OOP++.
I still think ruby is a bad language, even though I agree with you
- I found ruby horribly confusing until I got over the intial learning bump.
  Now I love it. It really is lovely. In terms of design that is. Not sure about the monkeypatching
Until you know a few very different languages, you don’t know what a good language is, so just relax on having opinions about which languages are better. You don’t need those opinions. They just get in your way.
This is wise advice for ANY domain of knowledge.
Lotta people get a little fragment of knowledge on something, then shut down their brain and stop accepting new input. But life is change, and to be able to change and learn new things you need to keep your mind open. Being able to relax on having opinions and keep learning and moving along is very important.
This is very true! Languages being unintuitive also becomes less of an issue the more languages you look into. There will be many concepts that multiple languages have since ultimately they are all trying to do similar things and the more you learn the more you will recognize making it easier to get into even more languages.

Dynamic typing is insane. You have to keep track of the type of absolutely everything, in your head. It's like the assembly of type systems, except it makes your program slower instead of faster.

Nothing like trying to make sense of code you come across and all the function parameters have unhelpful names, are not primitive types, and have no type information whatsoever. Then you get to crawl through the entire thing to make sense of it.
I'm not sure that's a hot take outside early uni programmers.
You can do typing through the compiler at build time, or you can do typing with guard statements at run time. You always end up doing typing tho
I like it in modern PHP, it's balanced. As strict or as loose as you need in each context.
Typed function parameters, function returns and object properties.
But otherwise I can make a DateTime object become a string and vice-versa, for example.
- What happens when you coerce a string to a date-and-time but it's not valid?
  Where I'm from (Rust), error handling is very strict and very explicit, and that's how it should be. It forces you to properly handle everything that can potentially go wrong, instead of just crashing and looking like a fool.
I kinda wanna say... skill issue? But really, dynamic typing is great as long as it fits the problem your solving and you keep your types simple or even just primitive

If you don't add comments, even rudimentary ones, or you don't use a naming convention that accurately describes the variables or the functions, you're a bad programmer. It doesn't matter if you know what it does now, just wait until you need to know what it does in 6 months and you have to stop what you're doing an decipher it.

However, engineers who rely solely on comments to explain their code, are bad at writing readable code.
- Possibly, but I'd prefer this scenario over the other.
it doesn't matter if you don't know what it does now
If I don't know what it does now my comment of "I have no idea wtf this does" won't help me in 6 months.
- Apparently, I've debugged your code.
Self documenting code is infinitely more valuable than comments because then code spreads with it's use, whereas the comments stay behind.
I got roasted at my company when I first joined because my naming conventions are a little extra. That lasted for about 2 months before people started to see the difference in legibility as the code started to change.
One of the things I tell my juniors is, "this isn't the 80s. There isn't an 80 character line limit. The computer doesn't benefit from your short variable names. I should be able to read most lines of code as a single non-compound sentence in English with only minor tweaks and the English sentence should be what is happening in most of those lines of code."
- Absolutely agree, yeah
- There's no such thing as self documenting code, unless every method and variable name has the word "because" in it.
  Anyone can read what the code does. The comments are there to answer why it does what it does the way it does.
  Why is invariably lost to time, if it's not committed to a comment here and there.
- 80 character limit is helpful though when you need to have many files open at a time. Maybe 100 is more reasonable. Fighting indentation is important too.
This is why code review exists. Writer's can't always see what's wrong with their work, because they have the bias of knowing what was intended. You need a reader to see it with fresh eyes and tell you what parts are confusing.
That's not to say you shouldn't try to make it readable in the first place. But reviewing and reading other people's code is how you get better.
Let's take this one step further. I should be able to get the core ideas in your code by comments and cs 101 level coding (eg basic data structures, loops, and if/then).

Tools that use a GUI are just as good (if not better) than their CLI equivalents in most cases. There's a certain kind of dev that just gets a superiority complex about using CLI stuff.

The big thing you can do from the command line is script it.
- Indeed, the problem with gui apps is when you can’t script them!
  I always loved alfred on osx, then loved scripting rofi on linux, only to come back to osx years later and find alfred can’t be invoked with stdin options. It’s damn shame….
I used to think something like this when I was younger. I spent an inordinate amount of time looking for good gui versions of cli tools. I have come to understand that this is not usually the case and cli tools are more convenient much of the time. I would not classify this as superiority complex, unless I’m being a jerk about it. I don’t care what you use, I just use whatever has the lowest barrier to entry with the most standardization, which is usually the original cli tool.
That said, jetbrains git integration is awesome.
- I agree only when your job function is specifically geared around those tools... Otherwise high quality guis are more valuable.
  Just because I can do everything in gdb that I can do in visual studio doesn't mean 99% of most debugging tasks isn't easier and faster in visual studio. Now if my job was specifically aimed at debugging/reverse engineering there are certain things that gdb does better on the CLI... But for most software devs... CLI gdb isn't valuable.
There are some massive intrinsic advantages of the CLI though, that apply for everyone, not just leetcoders:
The terminal can remember everything you ever did. Forgotten the command you wrote 2 months ago? You can do a search for it with a tool like fzfand run the exact same command again.
Communicating with others. GUI programs require step by step instructions, often accompanied by screenshots while CLI may be copy/pasted.
Combining programs together. There are a few different techniques for combining CLI programs to search/format output, use secrets without ever having them in the clipboard or on disk, monitor something frequently/constantly etc etc
So while I agree with you that there's plently of elitism around the CLI, you do yourself a disservice if you try to avoid it.
Just no. CLI can be automated, which makes it superior. It's not a superiority complex, it's a fact. I'm not a minimal wage worker pushing buttons I don't understand. I'm not a technician who learnt your shitty software to do the most basic tasks.
My gold standard app is a CLI where I have the option to visually add the flags. I'm thinking of the ytdlp-gui type programs.
- Which yt-dlp GUI do you use?
Aside from automation, CLI can support significantly more complicated apps reliably. It can also be tested more reliably.
GUIs are better for anything simple, and good UX designers can make a moderately complex one, but anything like server administration/git/configs are 100x better on CLI
This depends a lot on the GUI and the tool. Some cli tools are great alone or for scripting, others benefit from the extra attention to ux and exposure of options that a GUI can offer
For git in particular, I encourage juniors to learn and use the CLI. I find that GUI git clients often do some or all of the following:
Use non-git terminology that ends up being confusing. "Sync" comes to mind as a frequent offender, I can think of several incompatible things that could refer to.
Ignore the useful ability to stage your changes
Don't permit or encourage a review of the changes
Implement only the basics and make remediation of branching issues difficult
In the worst case, I've seen people end up using the git GUI like a "save" button, blindly commiting and pushing the current state of their code, including to-be-removed print statements and other cruft. Yeah, git cli is a bit complex compared to that, but you gain a lot for that added complexity.
That said, I've definitely jumped into a git GUI from time to time just for a visualization of whenever branching snafu I'm trying to untangle. None of the above invalidates GUIs if you take care to still understand the underlying tool properly!

My take is that no matter which language you are using, and no matter the field you work in, you will always have something to learn.

After 4 years of professional development, I rated my knowledge of C++ at 7/10. After 8 years, I rated it 4/10. After 15 years, I can confidently say 6.5/10.

This take gets colder as you get more experience.
Amen. I once had an interview where they asked what my skill is with .net on a scale of 1 - 10. I answered 6.5 even though at the time I had been doing it for 7 years. They looked annoyed and said they were looking for someone who was a 10. I countered with nobody is a 10, not them or even the people working on the framework itself. I didn't pass the interview and I think this question was why.
- Your mistake was giving them an answer instead of asking how the scale was setup before giving them a number. Psychologically, by answering first your established that the question was valid as presented and it anchored their expectations as the ones you had to live up to. By questioning it you get to anchor your response to a different point.
  Sometimes questions like this can be used to see how effective a person will be in certain lead roles. Recognizing, explaining and disambiguating the trap question is a valuable lead skill in some roles. Not all mind you... And maybe not ones most people would want.
  But most likely you dodged a bullet.
- Did your interviewer profess to be a 10 in .net, otherwise how would they know what that looks like? I was told that I'm unsuitable as a programmer of PLC because I never used their software before. That I write the algorithms that go into a PLC was not sufficient. These people are looking for unicorns but find donkeys everywhere they look.
- As a hiring manager, I can understand why you didn’t get the job. I agree that it’s not a “good” question, sure, but when you’re hiring for a job where the demand is high because a lot is on the line, the last thing you’re going to do is hire someone who says their skills are “6.5/10” after almost a decade of experience. They wanted to hear how confident you were in your ability to solve problems with .NET. They didn’t want to hear “aCtUaLlY, nO oNe Is PeRfEcT.” They likely hired the person who said “gee, I feel like my skills are 10/10 after all these years of experience of problem solving. So far there hasn’t been a problem I couldn’t solve with .NET!” That gives the hiring manager way more confidence than something along the lines of “6.5/10 after almost a decade, but hire me because no one is perfect.” (I am over simplifying what you said, because this is potentially how they remembered you.)
  Unfortunately, interviews for developer jobs can be a bit of a crap shoot.
Hahaha man I feel you
The mark of a true master.
Understanding how complex something is, is irriversible. Once you reach that plateau you will always know how much there is you don't know.

Programing is a lot less important than people and team dynamics

- The code can always be rewritten, it is irrelevant.
- Sure try to replace the one or two people that hold the whole team together. I've seen it a couple times, a good team disintegrates right after one or two key people leave.
  Also, if you replace half the team, prepare for some major learning time whenever the next change is being made. Or after the next deployment. 🤷‍♂️

Not sure if these are hot takes:

Difficult to test == poorly designed
Code review is overrated and often poorly executed, most things should be checked automatically (review should still be done though)
Which programming language doesn't matter (within reason), while amount of programming languages matters a lot

I agree with your first point, but pretty strongly disagree with the other two. Code review is critical. Devs should be discussing changes and design choices. One Dev can not be all things all the time and other people have experience you do not or can remind you of things you forgot. Programming language absolutely matters when you’re not the only dev on the team.
- If code reviews in your org are glorified "styleguide checks", then they are not really code reviews at all.
  Also, if you're only getting design input at code review time, that's WWAAYY too late in the process.
  Code reviews should be:
  Establishing that the code has proper test coverage (functional correctness VIA coverage, not code observation)
  Establishing that it doesn't have unintended consequences in the ** implementation** (making db calls in a loop, exposing secure information, etc)
  That the implementation is of the high-level design that was already established and agreed upon by the larger development unit.
  A opportunity to ask questions to learn from whoever wrote the code
  An opportunity for the reviewers to teach techniques that could have helped in the code
- Nice, so they are hot takes :D
  If the design of a code change is bad, noticing that in the PR stage is not desirable. It should be discussed before someone actually went ahead and implemented it. It can also happen if people misunderstand the architecture, but again, that should be cleared up before actually implementing a change. Code style should be enforced automatically, as should test coverage and performance. Code review is also pretty bad at finding bugs from my experience. That imo leaves very few things where code review is useful that are not nitpicking.
  As for programming languages, the amount does matter for individuals and for teams/organisations. A developer who can only use a single language is not very good, and using a many different languages within the same team is not good either.
Code review is overrated and often poorly executed, most things should be checked automatically (review should still be done though)
I think part of this is caused by the fact that a lot of people are bad at code reviews so they focus on things that a linter could have told you. Being able to read code isn't necessarily the same skill as being able to write it -- as evidenced by the knee jerk reaction to throw out any coffee we didn't write ourselves.
I still create code reviews when I'm working on a project alone because it gives me a different perspective on the changes I've made.
- It’s not that most people are bad at it, they are just out of context.
  Like, I am completely swamped with a completely different business area of the code, besides checking for obviously dumb things, what can I really tell about a diff to a very separate part of the code which I may have never worked on before, with business requirements I don’t understand as I was not part of the 10 meetings that happened between the dev of the given ticket and BAs?
Difficult to test == poorly designed
It's pretty much a natural law that GUIs are hard to thoroughly test.
- But does it have to be? I haven't touched non-web GUIs since 15 years, so my perspective on this is limited. And web frontend is not what I would call a well designed system for it's current purpose.
Imo reviews are more for checking that someone didn't drop malware into the code base. It's rare that I get a good review that goes beyond checking for malice.
I've been wanting to make my applications easier to test. The issue is, I don't know what to test. Often my issues are so trivial I notice them immediately.
What are some examples of common things in, let's say a web server, that could be unit tested?
- Good questions, I could probably write a lot, but I'll try to keep it short. I usually apply TDD and there are different schools of thought within it about how to structure the development process. But no matter how exactly you do it, if you focus on writing the tests while writing your code, you won't end up with an application that you then have to figure out how to test.
  what to test
  Well, what is the application supposed do? That is what you test, the behaviour of the application.
  So in a codebase without any tests, the first thing you should write a test for is the happy path. That will probably not be a unit test. So for the web server example, set it up in a test with a file, start it and check if it serves that file.
  Then you can add tests for all the error cases and for additional functionality. You can write unit tests for individual components. The ideal places to test are interfaces with clear boundaries. Ideally you should not have to look at the code of a method to be able to write a test for it. In reality that's not always so easy, especially in existing code bases, but if you have to set up more than one mock, it tends to lead to brittle tests.
  Every time you encounter a bug/issue, reproduce it in a test first. And do measure code coverage, but don't make it a target, just check for places that are lacking.

Python is only good for short programs

Python is only good for short programs
Was Python designed with enterprise applications in mind?
It sounds like some developers have a Python hammer and they can only envision using that hammer to drive any kind of nail, no matter how poorly.
- I feel attacked.
  By my own Python hammer.
- I mean, it's still a very nice language. I can see someone, marveled by that, would endeavor to make bigger things with it. I just don't feel it scales that well.
Python should not be used for production environments, or anything facing the user directly. You are only inviting pain and suffering.
I don't think the length of program matters so much, especially with type hints making it easier to maintain larger projects.
That being said, it's pretty well known in the community that distributing any kind of end user software is a nightmare with python (though there's a small group of people who insist that it's not that hard to get people to install python to run their program. Those people are nuts).
The biggest reason I use python for as many projects as is practical, though, is because it has an incredible community that I love to interact with. Unless I truly need something to be scalable, python is always going to be my hammer of choice.
Check out home assistant.
- I don't mean it doesn't work for larger projects. Just that it's a pain to understand other's code when you have almost no type information, making it, to me, a no go for that

Most modern software is way too complex for what it actually does.

SPAs are mostly garbage, and the internet has been irreparably damaged by lazy devs chasing trends just to building simple sites with overly complicated fe frameworks.

90% of the internet actually should just be rendered server side with a bit of js for interactivity. JQuery was fine at the time, Javascript is better now and Alpinejs is actually awesome. Nowadays, REST w/HTMX and HATEOAS is the most productive, painless and enjoyable web development can get. Minimal dependencies, tiny file sizes, fast and simple.

Unless your web site needs to work offline (it probably doesn't), or it has to manage client state for dozen/hundreds of data points (e.g. Google Maps), you don't need a SPA. If your site only needs to track minimal state, just use a good SSR web framework (Rails, asp.net, Django, whatever).

I'm still hoping for browsers to become some kind of open standard application environments and web apps to become actual apps running on this environment.
- How are browser not that already? What's missing?
  They are an open standard and used to make many thousands of apps.
I do a lot of PHP, so naturally my small projects are PHP. I use a framework called Laravel, and while it is possible to use SPAs or other kinds of shit, I usually choose pure SS rendering with a little bit of VueJS to make some parts reactive. Other than that, it is usually, just pure HTML forms for submitting data. And it works really well.
Yeah yeah, they push the Livewire shit, which I absolutely hate and think is a bad idea, but nobody is forcing me, so that's nice.
Actual hot take, Blazor is awesome, it is like Microsoft looked into ASP.NET Forms, ASP.NET MVC and Razor, and bundled it to one quick framework to do simple WebApps.
- Counter hot take, I do actually like Blazor but it has limitations due to how immature web assembly still is. It also does not solve the problem of being a big complex platform that isn't needed for small simple apps. Of the half dozen projects I've written in Blazor, I'd personally re-write 3 or so in just Razor Pages with Htmx.

The best codebase I have ever seen and collaborated on was also boring as fuck.

Small, immutable modules.
Every new features was coded by extension (the 'o' in S.O.L.I.D)
All dependencies were resolved by injection.
All the application life cycle was managed by configurable scopes.
There was absolutely no boiler plate except for the initial injectors.
All of the tests were brain-dead and took very minimal effort to write. Tests served both as documentation and specification for modules.
"Refactoring" was as simple as changing a constructor or a configuration file.
All the input/output of the modules were configurable streams.

There is more to it, but basically, it was a very strict codebase, and it used a lot of opinionated libraries. Not an easy codebase to understand if you're a newbie, but it was absolutely brain dead to maintain and extend on.

Coding actually took very little time of our day, most of it consisted of researching the best tech or what to add next. I think the codebase was objectively strictly better than all other similar software I've seen and worked on. We joked A LOT when it came time to change something in the app pretending it would take weeks and many 8 pointers, then we'd casually make the change while joking about it.

It might sound mythical and bullshity, and it wasn't perfect, it should be said that dependency injection often come in the form of highly opinionated frameworks, but it really felt like what software development should be. It really felt like engineering, boring and predictable, every PO dreams.

That being said, I given up trying to convince people that having life-cycle logic are over the place and fetching dependencies left and right always lead to chaos. Unfortunately I cannot really tell you guys what the software was about because I am not allowed to, but there was a lot of moving parts (hence why we decided to go with this approach). I will also reiterate that it was boring as fuck. If anything, my hot take would be that most programmers are subconsciously lying to themselves, and prefer to code whatever it is they like, instead of what the codebase need, and using whatever tool they like, instead of the tools the project and the team need. Programming like and engineer is not "fun", programming like a cowboy and ignoring the tests is a whole lot of fun.

This is the only way;

        if (condition) {
        code
    }

Not

        if (condition)
    {
        code
    }

Also because of my dyslexia I prefer variable & function names like this; 'File_Acces' I find it easier to read than 'fileAcces'

Internet would be better if javascript was never invented.

Compiler checked typing is strictly superior to dynamic typing. Any criticism of it is either ignorance, only applicable to older languages or a temporarily missing feature from the current languages.

Using dynamic languages is understandable for a lot of language "external" reasons, just that I really feel like there's no good argument for it.

Hot take: people who don’t like code reviews have never been part of a good code review culture.

Agile in it’s current implementation with excessive meetings wastes more time than the mistakes it tries to avoid.

Dynamically typed languages don’t scale. Large project bases become hard to maintain, read and refactor.

Basic type errors which should be found in compilation become runtime errors or unexpected behavior.

As an embedded firmware guy for 10ish years:

C can die in a fire. It's "simplicity" hides the emergent complexity by using it as it has nearly no compile time checks for anything and nearly no potential for sensible abstraction. It's like walking on an infinite tight rope in fog while an earth quake is happening.

For completely different reasons: The same is true for C++ but to a far lesser extent.

You can use all the classes, patterns, functions, methods you want but if it's not readable it's garbage.

Not everything should be beginner friendly. Trying to nerf things because they are not beginner friendly should not be how tools/patterns of languages are designed.

Its ok to have more advanced topic that require more knowledge and that people don't understand from the first moment they see them.

My hot take: Vi, make and C would have gone the way of COBOL a long time ago if it wasn't for a lot of programmers thinking "my tools are more difficult to use, hence I'm a better programmer".

I agree with C and Make, not with vim/neovim though
I agree. You should use Neovim instead of Vi nowadays. :P
- Yeah, its so much more interesting to edit code with only your keyboard. Always switching back and forth from mouse to keyboard is just too cumbersome.
  Bonus points for Neovim: It made me understand my tools (LSP, linting, CLI tools, TUI etc...)
Upvoted for make and c, highly disagree on vi/vim though. It's significantly nicer not having to use a mouse for 95% of my work. Need to delete between two quotations to replace it? v, i, ", d does it. Whole line? d, d. Beginning of end of document? G or gg. There are keyboards to streamline just about any movement or operation, and none involve the mouse. I still need the mouse for clicking stuff in vs code, but that's mostly just when committing.
Side shout out to emacs, it's lost popularity over time, but it can do just about anything
- For any interested Vi(m) user, one can install evil-mode to get vi keybindings in GNU Emacs.
I am triggered by that statement.
vi lives on because it's everywhere. On a remote machine and need to edit a file? vi is there.
As a person uses neovim, make and exclusively programs in C I am indeed triggered. Maybe you could argue Make and C are hard but Vi definitely is not (atleast the basics aren't).
Vi, make and C are elegant beautiful tools, and the joy they will bring into your life will wait steadfast and pure in spirit until you discover it.
I use the unholy IdeaVim and honestly... I love it. I won't pretend that interacting with a heavy IDE while using vim is a great idea, but it makes editing so much more comfortable.
Also while you can use something like nano for editing files in the terminal, vi(m) is much faster for more in-depth editing.

Shorter code is almost always better.

Should you use a class? Should you use a Factory pattern or some other pattern? Should you reorganize your code? Whichever results in the least code is probably best.

A nice thing about code length is it's objective. We can argue all day about which design pattern makes more sense, but we can agree on which of two implementations is shorter.

It takes a damn good abstraction to beat having shorter code.

Full IDEs kinda suck.

- Entirely agree with this.
  And at least as far as Firefox goes I'm running it on gnome and there's a beautiful theme that makes it look native for it. I'm sure there's one for windows too if you look.
- "I’d kill for an IDE on macOS that uses the native UI." Possibly dumb question from someone who hasn't used MacOS for ages: isn't that what Xcode is?
- Firefox is really badly integrated in MacOS. The fn + arrow shortcut doesn't work, for example, it's not integrated in the menu system (the menu shortcuts don't work) etc. But there is Sideberry, so...
Some languages really do suck so much they're all but unwriteable by plain text, and need constant compiler tree parsing to get right.
But that's an incentive to quit using bad languages. Write in something you can read and write in ed, and you can hold it in your head.
Not arguing either side, but I'd love to hear your reasoning.
- A linter a debugger and a clean interface in general are all I need. And most text editors suffice for that.
  I've never been able to benefit from an IDE in a way that make up for how much slower and more bloated they are.
  I'd love to hear what some of the main benefits are though.
- I think they mean xcode.
I love intellij. The gut Integration and diff utilities alone are worth using it. However, it is so. Fucking. Slow!
- Seems fast enough for me. Never really had to wait on the ide for anything
Python development without PyCharm (or IntelliJ) and the IdeaVim plugin is unbearable. List usages is a game changer. Don't care much for anything else.
- Whaaat? I program Python with plain vim. C or Java, on the other hand, with a large enough codebase, is unbearable without an IDE.
- Yeah, well, that's just Python for you. List usages is now an LSP feature for most languages, so will work with "lesser" editors too.
  All that being said, I use Intellij with Java daily, so I can see where you're coming from. But for example Rust or Go works wonderfully with Neovim (or VSCode).

Oop is overrated

I never can understand classes

Make your app use native components instead of making your own crappy theme for the 782th time

JS is horse shit. Instead of trying to improve it or using that high level scripting language as a compilation target (wtf?!), we should deprecate it entirely and put all efforts into web assembly.

Microsoft has not made a good product. Ever. Every program has issues that should not be there if you're selling it. Yet they get away with it

Web development feels like it's stuck in the early 2000's. I've ranted a lot about it over the years but I just don't know how everyone is okay with it. I'm sure tons of people will disagree.

HTML is bad. The language itself feels unintuitive and is clunky compared to modern markdown languages, and let's be honest, your webpage just consists of nested <div> tags.

CSS is bad. Who knew styling can be so unintuitive and unmanageable? Maybe it made sense 25 years ago, but now it's just terrible. It's very clunkily integrated with HTML too in my opinion. Styling and markdown should be one easier to use language where 50% of it isn't deprecated.

Javascript has been memed to death so I won't even go there. Typescript is OK I suppose.

And now for my hottest take: ~10+ years ago I saw web building tools like Wix and I completely expected web development to head in the direction using a GUI to create, style, and script from one interface, even allowing you to create and see dynamic content instantly. I've seen competitors and waited for "the big one" that's actually free and open source and good enough to be used professionally. It never happened. Web dev has just gone backwards and stuck in its old ways, now it's a bloated mess that takes way more time than it deserves.

The Godot engine is actually a pretty good option for creating GUI apps and it's exactly what I envisioned web dev should've been this past decade. One language, intuitive interface, simple theming and easy rapid development... Shame it never happened.

</div>

HTML is bad. The language itself feels unintuitive and is clunky compared to modern markdown languages, and let’s be honest, your webpage just consists of nested
<div>
tags.
My websites do not consist of nested divs. Your webpages might just consist of nested divs, but only if you are clueless about what you're doing and are oblivious to basic stuff like accessibility support.
CSS is bad. Who knew styling can be so unintuitive and unmanageable? Maybe it made sense 25 years ago, but now it’s just terrible. It’s very clunkily integrated with HTML too in my opinion.
Being unmanageable is the output of the developer team, not the languages they use. Decoupling Presentation from the data and semantics never ceases to make sense. CSS has many issues but the way its integrated with HTML is certainly not one of them.
Frankly, you sound like you blame your tools a lot.
</div>

HTML is bad. The language itself feels unintuitive and is clunky compared to modern markdown languages, and let's be honest, your webpage just consists of nested <div> tags.
Yet Markdown languages are far, far more limited in both scope and functionality than HTML is. How do you bridge this gap without making it just as complex?
CSS is bad. Who knew styling can be so unintuitive and unmanageable? Maybe it made sense 25 years ago, but now it's just terrible. It's very clunkily integrated with HTML too in my opinion. Styling and markdown should be one easier to use language where 50% of it isn't deprecated.
They didn't start by writing a spec with half of it deprecated already. They started with something, and over time kept developing it - and deprecating other parts. No matter what you propose, unless it's 100% absolutely perfect (and nothing ever is) you'll end up in the same situation. The only other choice would be to break backwards compatibility, which is obviously not a good thing to do.
And now for my hottest take: ~10+ years ago I saw web building tools like Wix and I completely expected web development to head in the direction using a GUI to create, style, and script from one interface, even allowing you to create and see dynamic content instantly. I've seen competitors and waited for "the big one" that's actually free and open source and good enough to be used professionally. It never happened. Web dev has just gone backwards and stuck in its old ways, now it's a bloated mess that takes way more time than it deserves.
People say the same about no-code frameworks. There's a good reason that stuff doesn't work beyond the absolute basics. If it was really possible, HTML+CSS+JS give you all the necessary tools to build it. You won't get there with a more limited system.
</div>

In unit testing, a "unit" does not have to be the smallest possible section of code. It can be a while class or module or even set of related classes/modules. Testing individual functions in isolation leads to brittle tests that easily break during refactoring. Testing overall system behaviour results in more robust tests that require fewer changes during refactoring which gives you more confidence then you have not introduced a regression.

IMO, you should usually test only stable interfaces.
If you have no stable interface all the way into the UI, then you shouldn't test anything all the way into the UI, and focus your tests there. Odds are that your code isn't very good, because it is rare that you don't need anything stable all the way through, but well, "rare" is not the same as "impossible".
This is the correct comment.
Martin Fowler called them sociable tests. The only way to properly test your units' behavior is to pull in their dependencies. Isolated tests are useless, brittle and slow to write.
- Yeah I'm of the opinion that unit tests are usually a waste of time and people should only write integration tests.
  The only time I think unit tests are valuable is for checking edge cases when e.g. interacting with the operating system.
- I actually love that they’re so brittle because it quickly catches problems that need fixing.
  Tests are not brittle when they catch actual problems. Tests are brittle when they break for no good reason. And really when you are refactoring something tests should not break - you are not changing behaviour, just reorganising things. If you need to do big changes, rewrite or even delete tests when you refactor something then your tests IMO are brittle and much less likely to catch regressions in behaviour. Yeah you will need to tweak them some times, but these should be kept to a minimum and not be happening every time you refactor anything.
  When writing new code small tests can feel good, they are easy to write and you can test things quickly in isolation. But after that point how much value do they give you? Tests do have a cost - beyond the original time you spent writing them, you have to maintain them, and keep them uptodate, they take time to run etc... If they cannot properly catch a regression when it happens then IMO they are not worth the cost of keeping them around. Larger tests tend to be better at catching regressions and are less prone to need to be tweaked when you refactor the internals of something.
  So, generally speaking I tend to prefer testing public APIs of something and ignore internal helper functions (unless some helper is sufficiently large/complex enough that it warrants extra dedicated tests, which is not common). Note that this does not mean public to downstream users of your library/script/binary, but also larger internal modules API that the rest of the application can use. Though I do find quite a few smaller applications you only need to test the actual public API from an end users perspective.
  A lot of that has to do with type checking and a lot of the methods would have huge consequences if they were off.
  Uhg, This is a big reason I don't like loosely typed languages. Yeah that might be one case where smaller tests are needed but IMO testing input types should not be required at all - that is something a compiler can do for you for free. At least assuming you have a strongly typed language. People always say loosely typed languages are faster to code in - but this benefit is completely lost when you spend ages writing tests for different inputs types that a compiler in a stronger typed language would just reject.

The programming languages you use, and the variety of languages you learn, deeply influence how you think about software design.

Software would be much more reliable (in general) if Erlang had become one of the dominant languages for development.

Go sacrifices too much for superficial simplicity; but I would like to see a language that's nearly as easy to learn, but has a better type system and fewer footguns.

Unit testing is often overrated. It is not good for discovering or protecting against most bugs.

Build/test/deploy infrastructure is a genuinely hard problem that needs better tooling, particularly for testability.

Python is stupid. Using non printable characters as anything other than token separation is just asking for trouble.

Just use a modern editor and you'll never have this problem
- You can work around most issues in any language with the right tools. That's not the point.
  If a design decision introduced a whole new class of errors it is probably just bad design.
The space is a printable character.
What trouble have you gotten into due to this?
- Just copy some code over into a not properly configured vim.
  People seem to forget that not everything is a fully configured development environment working locally on your laptop which attempts to fix the issues introduced by that design decision.
Add YAML to that for the same reason.
- Actually I did below! You are absolutely correct.
- NO
Is Haskell, YAML, or Sass also stupid? 🤔
- Absolutely yes. JSON and SCSS > YML and SASS
- YAML can die in a fire, thanks

If white space carries any function that the compiler/interpreter needs to know about like structure or scope, it's probably not a very good programming language.

I am not smart enough to effectively code with certain languages and design patterns and that's ok. There is nothing wrong with accessibility being prioritized or with making tradeoffs for the sake of reducing complexity.

Python is legitimately the best language by far for the vast majority of non-performance critical tasks, and most tasks that need to be developed for are not performance critical.

Heh, I was about to comment how my hot take is that Python is overrated. It's... fine and I don't really have anything against it for the most part, but I greatly prefer Ruby to Python.
I'm speaking purely about the language itself here, not any libraries available for it (since someone will always point out how great Python is for data work).
- My impression at the time was that Ruby and Python both caught on with people who were ready to be done with Perl.
  And, later, that Go set out to be a replacement for Java, but ended up being a replacement for Python for people who were ready for type checking and built-in multithreading.
- Me too! Even just the fact that only false and nil are falsey is enough for me to prefer Ruby. Being able to use ||= as an idiomatic one-time initializer is rad. Python's OOP bothers me in a lot of ways compared to Ruby as well. And don't get me started on Ruby's blocks. . .
Oh man, I actually like the language, but you made me think of my own hot take:
Python has inexcusably poor docs.
Just a smattering of examples, which aren't even that good, while failing to report key information like all the parameters a function can take, or all the exceptions it can throw. Any other popular language I can think of has this locked down and it makes things so much easier.
I really enjoy typescript these days. Is there a Python typed equivalent?
- Python has had syntax support for type annotations for a while now. The Python runtime doesn't enforce the typing at all, but it can be enforced by a linter or by your IDE. And I believe you can introspect the type annotations at runtime, because they are actually part of the syntax.
  There's even an alternative way of doing type annotations through specially formatted comments, just in case you might still need to write code that is backwards compatible with Python 2.
  @escapesamsara @navi @programming
- I'd argue, 99% of the code written is not performance critical in the sense that a different language could help. Either performance really doesn't matter that much, or it's an IO problem. You can process as fast as you want, if the DB takes 100ms to respond, you won't get below 100ms overall.
For bigger projects, anything with MANDATORY types is a must for me. Optional, not compiler checked hinting doesn't cut it.
Not that i hate the language, but I do hate the tooling around it. I don't think I've ever had a pleasant experience with setting up a Python project. And all the data stuff is just wrappers for code in other languages, making the packaging story even uglier, even harder.
- You're right now to compromise on this, but you can give yourself mandatory types in Python, using MyPy, if that's your only issue with it.*
  Because you don't need elegant subprocess handling, intuitive reliable logging, and don't mind needing a to autonate a linter to check for whitesoace bullshit.*
  **Python is my favorite language, actually. Really.

Using single character variable names is always bad practice

Software was a mistake

Except if your adhd includes the perfectionist trait, because then you will never get to write the next line of code.
This is actually a pro tip.
and how you could test it easily! it's incredible how much it helps for cleaner architectures
- I don't find this helps. More often your assumptions about how something might change are wrong and when the actual change comes in you can end up causing yourself more work undoing the abstractions you made. IMO keep things simple as you can for as long as you can and add in abstractions when they are needed and remove them when they are not. Write code that is easy to change when change is needed, not code that tries to account for all possible future changes as this is impossible to do.

Designing good UX can be as difficult as writing good code.

Source: Im UI/UX designer and project manager and also QA/QC and also devops and also write the specs and documentation. The only thing I dont do is write the code, DB schema and architecture . The hardest of all those roles is UX. The easiest is project management ("Did anything go tits-up today? No? Well carry on, then ")

Biases: I have no formal training in any of those things and was actually hired as a helpdesk tech.

We use too many libraries. This may be an actual unpopular opinion though. I find that the more a library tries to do, and the more dependencies it has itself, the more hesitant I am to use it. It just feels like a tower of cards ready to fall at any moment.

I'm not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.

I do use libraries, but only if they're absolutely necessary or if they're very focused and don't try to do a million things. It's not about size but complexity.

Oh boy, here we go (inhales):

Agile isn't that bad. People just believe they are more productive if they are "heads down" and not held accountable for what they write/do.

Functional programming isn't that great and doesn't solve all of the world's problems; it just pushes the issues with state to other parts of your design, and doesn't scale well in deeply nested solutions.

IDEs with proper code support (i.e. automatic structure analysis, autocomplete, etc.) are one of the best ways to deal with a large codebase that needs refactoring. Doing widescale refactors without one is asking for trouble. If you believe you don't need it, either your codebase is just that small (which is fine) or playing with fire.

Much of the advice out there on architecture and tooling isn't properly contextualized on the codebase, market, and team situation. If you believe you have the One True Architecture Solution, you are naive. (Ex. Microservices, large complex code pipelines, monorepos, etc.) Be especially wary of anything from FAANG engineering blogs unless you are also in another letter of FAANG.

There. Got it out of my system. Have fun dissecting it.

JavaScript isn't bad. Sure it has its quirks, but it's not as bad as everyone makes it sound it is

GNU make is confusing as hell and shouldn't be used in today's world.

MATLAB is an okay programming language when used in the right context. It’s intended for scientific applications, so trying to do your standard object oriented programming with it gets weird. I think we forget that some things were made for a specific purpose- you know, a hammer can’t do everything and all that.

PHP aint all that bad

Not everyone can or even should learn programming.

I actually like C.

I'm not a professional programmer, I just do mods mostly; C is too common for me to hate it. It was the first language I really used, too. I mean, I learned BASIC first but I didn't use it for anything outside of learning.
Me too. It's the only language that felt natural. Learning it was a breeze and I haven't needed anything it dosen't provide.
- You've never needed an array whose size is not known at compile time?

Not sure about here but is was a hot take on reddit:
Pointers are not that hard and really useful

I really love the project structure of C++. I know that it is an archaic design developed like this due to lack of resources, but I find packages extremely offputting.

The first reason is that splitting declaration and implementation across files makes it easier to figure out what something does.

Second reason is that I feel that I have more control over libraries and packages that have to be manually added to a project rather than using a package manager.

Third, I feel like modern languages iterate over too many versions too fast. C++ has version releases too, but I feel that versioning is handled better from time, compatibility and stability point of view.

SQL is the core language that everyone should be required to learn first and foremost.

TDD is overrated. Code coverage is extremely overrated. Both of these tend to lead to a morass of tests that prove the compiler works at its most basic level while simultaneously generating a surplus of smugness about the whole situation.

Tests have their place. Tests can be, and often are, valuable. But the easier the test is to write, the easier it would've been to just encode it into the type system to begin with.

If I spend more than a month away from a language or tool, I have to constantly Google how to do basic shit.
I do that or just reference my personal library of half assed projects

When writing software that will be deployed to a production environment, it's better to slow down and take the time needed to write a higher quality, more durable solution than to rush and quickly kick a product out the door.

I don't know why this is a hot take, but sometimes it feels like it is.

Even better is to ship small increments often.
Unfortunately in many organisations, leadership doesn't really understand that instead of reducing quality, scope should be reduced in order to ship faster. And developers rarely have a say in these things.
While I agree that it can be considered a hot take industry wide, I don't think for most devs that is a hot take, the ones whom I've seen ship broken stuff were rushed on tight deadlines and didn't have the experience/motivation/political capital to fight back on deadlines.
It's a hot take because managers won't let us :'(

I like 1-index because its what I learned first, and you like 0-index because that's what you learned first

Most frameworks are garbage and most programmers that use them have no idea how they work and that makes them shitty programmers. I hate when people use frameworks without even knowing why they’re using them.

SCRUM is good, actually

🌶️🥵Many people consume Facebook meta company's tech stack wholesale, don't know how to actually traditionally program their way out of a paper bag, and web dev and devops caused a massive layoff (250k people) at the end of 2022, start of 2023 because it was all vaporware. They consume the same software in droves if the other guy uses it.

There is an entire subculture around it that is just a bunch of medium.com writers, YouTubers and twitter handles just trying to get the clicks for their ad money. Some of these guys have never written valid software or done anything noteworthy. If you meet them head on you'd find they have enormous egos and can't find a counter argument when presented with reason.

I'll even add on that there are many programmers who don't know how to code outside a web app.

Why is something like [react, graphql, react ssr, devops, tailwind, unit tests, containers] vaporware?

there are other frameworks even with component libraries that are easier to read the code for large codebases, better maintained, and have cohesive full stack solutions, and even faster to develop in, to name one quasarJS or even just plain ecmascript
if you look at the anatomy of these enterprises using these solutions they've evolved to have micro front ends requiring armies of workers.
devops is a sales term, the actual implementation of it is so contextual that you'd probably find you don't need a full time job for it half the time and most are relatively easy to setup inside of a business quarter
not everything is Facebook scale: unless you're padding your resume why did some of these get adopted? How complicated does your app need to be? Did you really need to transpile JavaScript for it?
unit tests were code to test your code that you're going to have to functionally test anyways: you're telling me that you have to write your code...twice? How the hell did this ever get justified to mangers? Why did the culture not evolve into literal automated smoke tests of the actual builds, instead of testing whether a function that is probably type annotated is going to fire anyways???
docker/containers suck ass: great that they solved a problem but created a whole new one. we moved to python and JS which were JIT without artifacts and suddenly everything needs a generalized build system to run it. C lang variants and Rust lang compile to a binary you can just run... Ship the small ass binary not an entire container to run your shitty web app

You know the stuff I don't hear about?

Javascript and Python were steps in the evolution but never the end goal. I'd even say the same of java. There are new solutions but JavaScript in the browser especially should be replaced.
eye appeal is buy appeal
that eye appeal shouldn't always mean you need to use a library or framework; vanilla apps work okay too.
binaries/artifacts/installer packages > containers
automated testing of the actual end product
well written logging to the point someone can tell what the application was doing without seeing code
using all these compsci algorithms to actually write new products and searches from scratch instead of being a framework baby: do you actually need ELK or Splunk for your search? Really?
you probably don't need MySQL for a lot of projects, I bet you an async library with sqlite would be the same for many of these projects.
small teams with feature rich apps using SSR, the value of an SSR web app
the value of a SPA
the value of traditional desktop software and not using REST APIs

Carbon? Just what we were all hoping for, yet another programming language from Google. They can keep it.

If programmers stick to what they know and not try to solve every problem at hand with the latest thing/programming language they've learned then there would be fewer bugs and projects would end by the estimated dates.

The only thing a GUI text editor can be better at than a terminal editor is making it easier to use the mouse.

Mandatory pull requests + approvals within a team are a waste of everyone's time.

Big hot take to me; especially in an organization with a large size and code high standard
We'v known this for twenty years and had the data ta back it up for ten. Github flow is one of the most damaging things to ever happen to software teams
- Source?
- what data? just curios because there are so many ways to do PRs properly.. like for everything, if it's done badly better not do it. does not mean it is inherently bad
depends on the company/team culture. are other people gonna have to fix or extend code you wrote? are you the sole engineer working on entire modules? do you hate feedback?
You must trust your team's abilities more than I trust my own. How often does your team merge bugs into main? We use CI primarily for running the full test suite, including integration tests and e2e tests that would be very difficult to run locally due to them using specific credentials to access testing resources.
- If your team consists of people you don't trust, that's the problem to fix first.
Depends how good you are at what you're doing. I'd argue that humans err and it saves a bunch of time to catch bugs before debugging in the wild
Unless you have people that are known to delivery garbage code. Which is more common than you would imagine, lol.
- The solution to that is pairing - spending a few hours collaborating with, and teaching this person will get them up to speed much faster than asynchronously nitpicking their code.

Composition over inheritance has become a meme that people repeat without understanding. Both have their uses, but if composition is all you use, then you're using a hammer on everything. There is no silver bullet in life and most undeniably not in programming.

Also, electron has a reason for existing. If it didn't have a use, it wouldn't have the number of users it has. You can't tell me in all seriousness that Qt, Gtk, Swing, Tkinter is easier to use than electron for the common developer.

Duplicate code can be a code smell, but it's far better to have the same function definition or code block appear twice in the code than extracting a function that tightly couples two components that should not be coupled at all.

See Write Everything Twice (WET) principle.

Oh I have some!

Computer science is still a hobby and has a lot to go through before it is an actual industry.

Developers are too often bad engineers.

Short development cycles are a bad thing.

POO is trash. It's a manager tool, not an engineering one.

Developers are too often bad engineers.
This I agree with, but would excuse it by simply stating investment isn't there for proper engineering standards. I'd love to produce bug-free tested to reasonably unbreakable, ethically implemented code every single time. But I'd be out of a job pretty quickly and replaced by someone willing to do it faster with more critical bugs and no thought of the ethical implications of a failure.
As an industry, we like to think of ourselves as supremely rational, but we can't apply even the most basic scientific principles. So much conventional wisdom has never actually been tested or proven, so we keep reinventing and flip flopping on best practices.
what is POO? Can't find a definition on google
- @sbstp @bouh I can just see people giving fecetious answers to this question.
- Ah it's French for object oriented programming

That the entire industry is cyclical and the current trends are yesterday's anarcisms. Oop Vs functional, separating concerns Vs vertical slices, there's examples all over the place.

All of this has happened before and all of this will happen again.

Here's another: most code reviews on larger companies are BS, just for show and nitpicking.

I work at a small organization where code reviews are good, but I've noticed that the larger the code review, the faster it needs to get done in order to avoid merge conflicts, which means large code reviews are much less effective in proportion to the size.
- I’ve noticed that the larger the code review, the faster it needs to get done in order to avoid merge conflicts, which means large code reviews are much less effective in proportion to the size.
  Exactly. And in larger corporations where you have many people contributing and the code is moving fast, having people nitpick your PRs just for show is crap because it delays everything sometimes by days. I had to say no very clearly to some people on code reviews because they were demanding me to place variables in alphabetical order on hard PRs that took quite sometime to get working and were very prone to code conflicts.
Here’s another: most code reviews on larger companies are BS, just for show and nitpicking.
Story time.
Once I worked with a developer that just joined the company straight out of college, and had far more ambition than competency. That developer decided that code reviews where the venue where their high bar for code quality would shine, so they decided to nitpick everything that went against their poorly formed sense of taste. As luck would have it, the developer was assigned to a legacy project that was in cold storage for years and had no tests and linters, and was in a really poor state, and proceeded to leverage that to challenge each and every insignificant detail such as if a space should be at the left or at the right of a symbol. Each code review automatically received dozens of comments nitpicking whitespace changes. What a waste of time with so much noise.
I drop by the project, and noticed the churn that developer alone forced upon everyone, as that team had a rule that all code reviews should be passed by all reviewers and that reviewer made it their point to reject reviews that didn't complied to their opinion on whitespace. So the first thing I did was onboard a code formatter, and made it my point to subject the spec to an unanimous code review. That problematic developer made it their point to nitpick away each and every single setting, but it turned out some of their opinions conflicted with previous feedback.
So the code formatter tool was onboarded onto the team. Did that stopped the problematic developer from continuing their nitpicking? No. Except this time around other developers started pushing back because the opinions were contradictory and contrasted with the official code formatting style.
All it took was a couple of days for the problematic developer to go from dozens of comments per day to zero. The code formatter was still optional and not fully adopted, but the problematic developer simply ceased with the bickering.
- I wish this had been my experience. I pushed for so long in my last company for standards to be written, code formatters implemented and objectivity to be brought to reviews but it was always ignored.
  Instead I had to endure every employee who claimed seniority (in a non hierarchical company) subjecting their opinion on style in reviews. It came up the point that I dreaded having to work with specific people because they kept triggering my PTSD with their moving target of micro management.
  Only afterwards did I truly appreciate how poor a lot of their opinions were. Now one of my first questions when approaching a new project is what standards we're following. If they look at me blank faced that's a pretty solid red flag.

My experience with people from university is that they have extremely strong opinions about things they don't know very much how they work outside theory. There is this syndrome that you have to do everything from scratch with low level languages and keep shitting on anything that uses abstraction to make your life easier.

I don't know why people in this industry have this need of feeling that they're better than others.

Having fun when programming should be much more important than having correct or fast code when you're a programmer and should be what we should aim for first.

If your function is longer than 10 statements, parts can almost always be extracted into smaller parts. If named correctly, this improves readability significantly

Strong typing is for weak minds.

You absolutely do not need a computer telling you what types you can put in a collection. Put an assert, write some unit tests, if you aren't sure where data sources come from and can't write a one-line comment.

Dynamic typing makes you fast, it's empowering. Try it and quit being so scared.

No matter how many unit tests or comments you write, it's impossible to "prove" type correctness in a dynamically typed language - and it will eventually blow up in your face when you have to refactor. There's a reason for the adage "testing can't prove the absence of bugs."
People like static typing because it offers strong guarantees and eliminates entire classes of bullshit bugs, not because they're "weak minded."
- Typing can't prove anything, either. It just creates bugs and crashes.
  Your program logic is the part that will not be fixed by it.
I agree, strong typing is for weak minds. I work with a weak mind so I want strong typing.
There's no difference in speed between typing disciplines. In point of fact, there cannot be. You must know the structure of your data to program against it. Whether you write it down explicitly or implicitly changes nothing but the location you wrote it down.
How is dynamic typinf faster? Is typing num = 1 instead of int num = 1 really that much faster?
- Plus, most statically typed languages either do type inference by default or let you opt in somehow.
  Even Java, which is probably the reason everyone hated static typing for the first decade of the century or so, now has var.
- I'm not any faster in languages without static types. It's the opposite, I'm fastest when I can write accurate type hints, since it makes the editor experience much better.
Until you're oboarded on a codebase that's heavy on tech debt and that also doesn't have proper documentation of the data being used.
- Terrible projects are terrible because of the developers, not because of the language.
  I find dynamic projects easier to refactor and fix, just write some tests and if it's green bar before and after, you're fine.

My mantra has always been to bring solutions not problems. Applying that to code reviews makes for a far more productive experience.

Rather than just pointing out errors in code help the developer with prompts towards the solution.

Or, if you're too lazy to explain why something shouldn't be done then why should another developer have to act on your criticism?

Abstraction will be the death of traditional software development as we know it

A lot of programmers need to work on their soft skills.

Modern PHP is great and people judging it by PHP 5 (version that's almost 20 years old) are idiots.

Write the whole thing, and only then, scrap it and rewrite it. This way you actually have a good understanding of the entire implementation when you are rewriting. When I refractor while writing my draft I will slow myself down and trip over myself, I'll be way more likely to rewrite something I've already rewritten.

Sure there is a limit to the size of projects this can work for, but even for massive projects they can still be broken into decently sized chunks. I'm just advocating for not rewriting function A as soon as you finish function B.

Write the whole thing, and only then, scrap it and rewrite it.
Exactly. And that's the part a lot of folks don't understand about writing tests. If we're not sure an interface will survive into the rewrite, it probably doesn't belong in the test suite.
And the rewrite can be very fast, if we tested the right things.

The amount of unqualified people is staggering beginning with those who have no university education.

Answering my own question here. If you don't have any interest in how the tools you use work, programming isn't "for you" (take that with a grain of salt). If you are writing code and have never looked into how compilers/interpreters work or are using a library and haven't even taken a peak at the library's source code you should because it will make you a better programmer in the long run. And I'm not saying you can't get anything done without that curiosity but curiosity is a major part of being a programmer. Also you don't need to have a deep understanding of the tool just a overview of what it's doing. Like for a compiler understanding what lexers, parsers, ASTs, code generators are will allow you to write code with that in mind.

Doing this is a hot take, but "clean architecture" is a joke.

My company is obsessed with it.

Python, and dynamically typed languages in general, are known as being great for beginners. However, I feel that while they’re fun for beginners, they should only be used if you really know what you’re doing, as the code can get messy real fast without some guard rails in place (static typing being a big one).

All programming languages suck, therefore the language you use doesn't matter

If you're not a programming superstar you can probably make more money writing nothing but Terraform code for hapless enterprises.

Good programmers need to be creative, flexible (soft skills with others), critical thinkers, and problem solvers. Lacking those kinds of features makes for a rigid and terrible programmer that is near impossible to work with or code behind. Leave the ego at the door.

Python should replace JavaScript on the browser

This one is problematic. JavaScript has many flaws but it's design of continuing to run through errors is beneficial to front end web development where the developer has no control over the environment.
Although I do believe Javascript is a mess, I'd have to disagree with that. The problem with Javascript and to an extent all client side code is that people uses as a everything tool not neccesarily the language being at fault. People should start to realize handling logic on the backend is perfectly fine and is often better as you don't need to send several megabytes just to load a simple web page. If we decided to replace Javascript with Python we just recreate the same problem that plagues the modern web.

I find that S-expressions are the best syntax for programming languages. And in general infix operators are inferior to either prefix or postfix notation.

In case you haven't heard, Factor just had a new stable release, and is tons of fun for postfix enthusiasts.
- I never understood how concatenative programmers can hold the current state of the stack in their head and never get confused about what is where, especially when changing complex code.
- Thanks, i hadn't heard oft Factor before, it looks interesting. I'm more of a LISP and FP Person but always wanted to properly learn a stack based language, Factor seems like a nice alternative to Forth for that purpose.
100%! It was mind-blowing to realize lisps are actually syntactically simpler than all the non-lisps so popular today
Takes a bit of love from editor standpoint unfortunately, so most devs will just never attempt that hurdle

Types and unit tests are bloat that increase the maintenance cost of whatever code they are involved in. Most types force premature design/optimization. Most unit tests lock up some specific implementation (increasing cost of inevitable refactors) rather than prevent actual bugs.

Nil-punning in clojure has spoiled me rotten, and now every other language is annoyingly verbose and pedantic.

Don't enforce using the same tech stack on each new project. When customer, domain, environment, requirements etc differ, so might the tool suite, languages, frameworks etc

If your code files don't contain more lines of comments than lines of actual code, then you're doing it wrong. (For Python, docstrings count as comments)

And your comments shouldn't say what each line of code is doing. If you can code, then you can already tell what each line is doing by just reading the code. The comments should explain WHY it's being done this way, or HOW it's being done, or highlight some pitfalls that might snare a future developer, and generally just give some higher level context to a line or block of code.

@257m @programming

Oh fuck I hate encountering this level of commenting. If it's complicated, you should have a design doc. Source code is not where you write your dissertation. Simple explanations are good, especially since the code could be updated while the comment is likely to remain unchanged. Long expositions are usually the result of bad coding or improperly allocated design.
- Absolutely agreed. If your code line by line isn't clear, then the code is the problem.
  Commenting before a block of code (a function / algorithm or whatever) explaining what it is meant to do, absolutely that's great though, saves time when revisiting.
@TerrorBite @257m @programming
Comments are for revision control systems. We have a strictly no comments in code policy because comments too often end up being wrong or misleading throwing everyone believing in them for a wild ride. The only thing that is worse than bad code is bad comments.
When you read sensible and thorough commit messages you generally have the notion that whatever it says was probably true at the time of the commit, whereas when you read comments in code it can still be correct or just plain utterly wrong.
- @nthcdr this assumes that people write sensible and thorough commit messages, instead of brief five-word ones or, say, song lyrics. Both of which I've seen.
  I at least try, except maybe for the other day where my commit message consisted entirely of an exasperated "why", followed by a revert.
  That being said, every commit message where I work is required to contain a ticket number (and the server will reject the push if you don't) so at least there's that for context.
  @257m @programming
I left the company, worked at other places in other languages, the company restructured, moved to India and back, got new premises, headhunted me because someone remembered that I wrote this particular system (serial port controller for certain industrial machinery). When revisiting code that I wrote 15 years ago, I was glad that my comments explained what I was doing, and why, and how, because all the other documentation was long gone. Don’t imagine that the original design documentation will still exist when you come back to it.

That the HTML/CSS structure of web programming is absolutely disgusting and not necessary. The internet could be and should be so much more from a developer pov. Also people who double space instead of tab often have their mouths open while mashing space 16 times.

I completely understand and clearly see that web development is the future, but I still think it’s all gross and will always prefer targeted efficient compiled code. Why? Because I’m a huge fucking dork.

My crazy take is that there needs to be a interpretative language alternative to Python which uses brackets to define scope and/or things like elif/else/fi/endif/done. Much easier that way in my opinion, and the ";" shouldn't be necessary. I'm used to Python, but if I had another language which can be used to serve similar purpose to Python with those features, I would never code in Python again when it comes up.

Having to code in Julia and G'MIC (Domain-Specific Interpretative language that is arguably the most flexible for raster graphics content creation and editing), they're the closest to there, but they're more suitable for their respective domain than generic ones.

Have you heard the good news about our lord and savior Ruby?
You might enjoy Ruby
- Here's something weird. I haven't written a ruby program in 15 years, but I still use irb as my calculator.
Sounds like Bython is the language for you! (only half-joking)

You can never have too many children

Real programmer learned Assembly.

VHDL is a good language.

If you think to be a good programmer, you're the opposite.

Spaces look the same on every screen.

Log levels are superstition.

Pure text is probably not the best way to write code, even if it is the most interoperable format

Easily the most triggering thread I've ever read.

I'm out of here.

There are two many programming languages and frameworks. There is a lot of doubling. Why the heck is there Dart/Flutter? Just use Javascript/TypeScript. Why Swift, when you have D, Go, Rust, Python with type annotations, etc.? In my opinion, just too much waste. Of course, in a niche, like OS development or embedded, there can be actually a need for hyper optimized special solutions. But the "mainstream" rest?

People who insist on using semicolons in Javascript don't understand why and are just following a cargo cult.

Remove the semicolons, be free.

Edit: lmao I hit some nerve here

Don't be afraid to drop a tool although you've spent years mastering it if there is something new that is much more efficient. Some day you have to switch anyway.

I'm not convinced that "strong pairing" is the best way to pair but even people who rail against agile ideology tell you that you're pairing wrong if you don't follow it precisely.