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.
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.
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
Corps != people.
People just pass the buck and nobody stands up for what is most correct
deleted by creator
This
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
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.
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.
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.
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
We used to call this ‘Code is Cheap’ at my last job - you’re spot on about the value of it
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
inton 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.
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.
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.
Programing is a lot less important than people and team dynamics
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.
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
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….
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.
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.
- 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
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
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 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.
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
Python is only good for short programs
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).
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.
You can always solve a problem by adding more layers of abstraction. Good software design isn’t to add more layers of abstractions, it’s to solve problems with the minimum amount of abstractions necessary while still having maintainable, scalable code.
There are benefits to abstraction but they also have downsides. They can complicate code and make code harder to read.
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.
Internet would be better if javascript was never invented.
