Programing is a lot less important than people and team dynamics
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.
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)
Been with a lot of codebases that had no unit tests at all and everyone was afraid to change anything because the QA process could take weeks to months.
The result is you have a codebase that ages like milk.
Our company motto is: “leave it cleaner than you found it”
Doesn’t everybody agree with this? I really never thought of it as a hot take.
I highly doubt most corps do
Corps != people.
People just pass the buck and nobody stands up for what is most correct
deleted by creator
Most calls I have at work are like group therapy sessions, as everyone has ideas of what they believe is correct, but they know if they keep pressing with management or take the time to do what is right, it won’t go well for them.
This is coming from a guy who lasted a year and a half in the office. Sounds like it’s a systematic issue…
deleted by creator
This
deleted by creator
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.
We used to call this ‘Code is Cheap’ at my last job - you’re spot on about the value of it
Yes please. Many times when I add a feature I end up refactoring some of the code first to better accommodate it.
thank_you_michael_scott.gif
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
Not everyone can or even should learn programming.
Using single character variable names is always bad practice
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.
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.
Most modern software is way too complex for what it actually does.
The only thing a GUI text editor can be better at than a terminal editor is making it easier to use the mouse.
Python is stupid. Using non printable characters as anything other than token separation is just asking for trouble.
Add YAML to that for the same reason.
Actually I did below! You are absolutely correct.
Is Haskell, YAML, or Sass also stupid? 🤔
YAML can die in a fire, thanks
Absolutely yes. JSON and SCSS > YML and SASS
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.
It also greatly improved readability of the language. Since switching to the standard of using 4-space tabs, I’ve not had any problems except when dredging up someone’s old Python 2 code.
You can create some really ugly code in spite of the forced indentation in python. Indentation does not really help here at all. In all languages you can correctly or incorrectly format things. A code formatter strictly applying a coding standard helps far more here than indents vs bracers. Take a look at black it takes the pep8 standards and adds more strict things on top making code look a lot more consistent and thus makes it easier to read.
And all formatters will indent code consistently, so having it as part of the language parser does not really help improve readability at all. And even without a formatter everyone I know will still correctly indent their code no matter the language used. But sometimes forcing new lines to have a meaning does make things worst - just look at pythons lambdas which have to be a single line.
Indentations does not really help readability that much in case of really, really, long code, and in some cases, a code can execute without with unexpected result because of one single indentation being off. Both of these why I like things like curly braces/brackets and terminators like endif/fi/done/end/etc. But, at the end of the day, if there’s a readability problem, then that’s a sign that the code needs to be reworked on.
Oh I think indentation helps a ton with readability. Even for bad, long or otherwise hard to read code - it would be way, way worst with no or wrong indentation. Correct indentation helps a lot. It is not the only thing that can be done to improve readability but it is the first and simplest fix you can apply to a code base. So a language enforcing it with syntax does not matter when even basic text editors can correctly and automatically indent your code.
Though one thing I do like about bracers is I can be lazy with formatting and let my formatter sort it out for me on save. With a white space sensitive language you need to get it correct from the start or else the program just does the wrong thing.
I didn’t say it doesn’t help. But, it alone does not really help for bad and long code, but you are correct in that it would be worse with the wrong indentation. Like you pointed out, the program could do the wrong thing if there is a wrong indentation where indentation matters which is one of my issue with something like Python. And languages with explicit exit scope tend to not have that issue while adding to the benefit of making longer code readable. Where white-space sensitive languages really shine on in my opinion are small codes, and that’s where I think of using Python.
It’s a choice, do you want to deal with brackets or indents? Pick one
deleted by creator
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”.
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.
But why?
Emacs editor commands are kind of clunky, you hold Ctrl or alt a lot and the movement commands are less intuitive and smooth than vi/vim keyboards imo. I’ve heard it described as: emacs has a text editor, vim is a text editor. Vim is great at editing and moving around in documents, selecting and editing text, and basically anything editor based. Emacs can do notes (org mode, linking notes, searching notes, etc), web browser, file browser, git (better git interface than vim), calendar, agenda, music playing, email… and that’s all without plugins
vi lives on because it’s everywhere. On a remote machine and need to edit a file? vi is there.
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.
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 am triggered by that statement.
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.
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.
It’s a hot take because managers won’t let us :'(
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.
deleted by creator
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….
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
fzf
and 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.
- 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
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.
deleted by creator
It also depends on the specifics — in many cases when a GUI is just a wrapper over the CLI tool, it is instructive to learn the CLI, similarly how you are a better programmer if you know about at least a layer beneath the one you are programming at (e.g. you can reason about this usage of hashmap because you roughly know what it does).
It is probably the most visible in git, but if you can only do commit and push from a GUI, just please learn the CLI as well. You don’t have to use it, but understanding it is important and the GUI may abstract away too much from you.
deleted by creator
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.
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.
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!
-
I don’t know, a tool we use at my work has a git GUI integrated, and it breaks all the time, lol.