257mWhat are your programming hot takes?
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 :'(
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.
bob_wileyThis would also create significantly less technical debt.
…but it can be nice to dabble.
I’m a Ruby developer but recently needed to solve a problem from within a non-Ruby Kubernetes container.
If I stuck with what I know I would’ve had to include the entire Ruby runtime into a totally unrelated application’s image.
Knowing exactly how to solve the problem in Ruby but not wanting to add hundreds of Ruby scripts everywhere, I found Crystal was the perfect fit for my needs.
I was able to write a slim sidecar container. The Dockerfile compiles it into a static binary, trashes the entire toolchain (FROM build) and the resulting image is just a few megabytes.
I think failed estimated dates just highlight how much we don’t know about ourselves, our systems and our own knowledge.
It is the abyss of the unknown talking back to us. We have the privilege of having the stuff we don’t know thrown back at us to prove us wrong. And we often fail to be humbled by it.
Much of the job is dealing with the unknown. A surprise in scheduling can either shorten a task or lengthen it. It can’t be shortened past the time it takes to recognize it’s finished, but it can be lengthened indefinitely.
millionRefactoring is something that should be constantly in a good base, for every story. As soon as people get scared about changing things the codebase is on the road to being legacy.
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.
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
I work at a big corpo and the people that make up it believe this.
Standing up at the wrong time is how you end up on the list to get laid off. 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.
A good manager likes to be told they’re wrong and how things should be done, but those are few and far between.
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…
It is. I’ve lasted almost 18 years. Things come in waves of good and bad. We’re currently in some bad times.
FlumPHPToday 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.
Only if the code base is well tested.
markAnd also try to make tests that don’t have to change if you refactor in future (although there are some exceptions)
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.
I guess I need to refactor for readability. What you just explained is the entire point of the comment I posted. Refactoring is part of the job. Don’t give your manager a choice on whether or not it needs done.
Our company motto is: “leave it cleaner than you found 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
russWe used to call this ‘Code is Cheap’ at my last job - you’re spot on about the value of it
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.
I don’t know, a tool we use at my work has a git GUI integrated, and it breaks all the time, lol.
The big thing you can do from the command line is script it.
Which means a person doesn’t need to become that good with the command line, they just need to learn the commands long enough to write the script and then never think about those commands again.
I’ve written a lot of scripts, but if someone asked me to do what the script does at the CLI with no man pages or anything, nope. Can’t do it, and I think that’s probably a good thing.
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’d argue the GUI has the lowest barrier to entry as it eliminates the need to learn any syntax or look up which switches to use.
If someone use a particular CLI tool often it can be quick and easy to do something, but for the occasional use, a GUI is much easier, assuming it has the required features a person needs. Can I use sed to replace a bunch of text in a file, sure, but it’s probably be faster and easier to use a text editor since I’m not using sed everyday.
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.
I agree, for a power user there is some value there.
I’ve used the git CLI, but find it a bit tedious. I also find a lot of value in the GUI providing an easy diff reference before a commit, at least in the app I use most of the time. There are some things the GUI can’t do, or it’s too weird to do, so the CLI is still handy.
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.
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?
On windows I was using youtube-dl-wpf
That’s the gold standard as far as I’m concerned. Haven’t used the ytdlp-gui yet, but it’s simple stupid… I might want a few more switches (more exactly the extract audio/subtitles) to turn
stilgar [he/him] 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.
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 accepting, others benefit from the extra attention to us 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!
Most frameworks are garbage and most programmers that use them have no idea how they work.
It drives me nuts when someone on SO asked a question about JS and all the answers use jQuery. It’s not as much of an issue these days, but for a while it was almost every post. I really questioned if people knew the difference.
For their credit basic javascript is a garbage language.
Sure, but there is nothing jQuery can do that basic JS can’t, just with extra steps.
I was working in an environment where jQuery (or other frameworks for that matter) couldn’t be used, so I had to cut my own path most of the time. I learned a lot about JS and CSS that probably would have been obscured away behind jQuery and Bootstrap had I not had those restrictions.
If someone is asking for a solution in a particular way, there is often a reason. Too many people skip that and provide it in what they know or are currently using, instead of what the user needs. These days I can imagine someone needing help changing the text on a button and someone telling them they need React, with some overly complicated solution to just and prove how smart they are, when all the user needed was how to set the innerHTML on their button element.
Oh I agree that questions are two often badly answered! The exemple of “why don’t you use this instead” is the worst offender. I didn’t understand you were talking about this, and I’m still traumatised by javascript after 14 years.
Yes…and, worse yet, the jQuery responses are almost never a good way to do things or they use things that are deprecated. It’s a hot mess out there.
FuckBigTech347This isn’t limited to JS. Too many times have I seen someone ask a question of how to do XYZ in language ABC where most of the replies were some form of “Just use this library bro” while not actually answering the question. And usually the library that’s being suggested is some big monolith that implements a ton of shit that no one really uses.
Yeah. In my case I don’t have the option to install random libraries, so those replies aren’t helpful.
It’s fine to call out a library that can make things easier, for those who can use it, but it can’t be the only solution.
Hey us programmers only listen to our engineers or architects. Blame them.
buh [she/her, any]I like C# and Visual Studio
I’m guessing you are not programming on a Mac then :-).
C# is great. VS is fine, but being bolted to Windows is no go for me.
C# is great but I’m going to say that if you love VS it might be evidence of a previous head injury
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.
Absolutely. I don’t know if it’s the absolute best, but I very much agree for using a high-level language for high-level tasks. There’s a reason they’re designed that way—you’re not burning Hertz, dang it; you’re burning seconds, and you’re burning them either way!
That said, please, please don’t use it for performance critical code.