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.
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.
I highly doubt most corps do
Corps != people.
People just pass the buck and nobody stands up for what is most correct
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.
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.
Tabs are better than spaces
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.
deleted by creator
You know, I wish it wasn’t. Much of Amazon was on a version of Perl for years (and may still be) for almost all of their front end hosting. Facebook has transformed PHP into Hack (which is better for types, though technically not strongly typed), strongly suggesting they were running PHP until 2014. Let’s not forget what WordPress is still in PHP too.
Not really a hot take. Why do you think most dynamic languages have the option to tack on static typing?
Depends on the community. In Lisp communities, for example, it’s very much a hot take. Which is a shame, because I’d love a statically typed Lisp-like language.
We can feel it in our bones… And boy is it a pain when you find a huge codebase that is JS only or python without types. Fucking hell dealing with that shit
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’
It depends for me. If the condition is some goofy ahh multiline syntax hell i like to use the second option.
Even then - ) { on a newline.
I think it would be a much hotter take if you had the opposite opinion. I’ve only met a few of those.
I’m not a programmer (I tried learning programming and unity but got lazy so…) but when I learned about if-then statements, the second one seemed like the way it’s supposed to be; I mean it looks so clean and simple. Do actual programmers prefer the first method?
I prefer the first method because it reduces the number of empty lines I have to scroll past and visually filter out
The 2nd is the style guide used in C#, and therefore what you’ve encountered in unity.
I use all 3.
If it’s very short and there’s 2 or more in a row, I’ll put it all in one line.
If there’s a bunch of nested if statements, I’ll use the second.
If neither of those conditons, I’ll use the first.
I’ve only seen the second type in C#, to be fair it makes code neater but i’m glad I left it for Java.
How does it make code neater? All it does is add a ton of empty vertical space. It makes files arbitrarily longer at essentially no benefit.
Agile in it’s current implementation with excessive meetings wastes more time than the mistakes it tries to avoid.
Blame management for that. I implemented Scrum in a project that I took over without any changes to the framework and it is great. We are able to keep a healthy work life balance, no overtime, good relationship between the product and the engineering team, and the most important thing is on time feature delivery.
Interesting you prioritized pointing out on time delivery as opposed to maximum value.
Hits a sore spot, I’ve delivered a lot of useless stuff on time with agile teams. We could have been useless even faster without the meetings.
Hey, the one responsible to maximize the value is the Product Owner, not the devs. We’re only responsible in taking the PBIs in the backlog that’s ordered based on value and delivering it. Whether it is really valuable or not is the responsibility of the Product Owner.
Not an Agile issue, but a “people fucking up Agile” issue. The priesthood of MBAs will adopt whatever terms people like and just hammer them into place to keep doing the same old shit.
I have experienced this but I think that’s the fault of the people implementing it.
For instance, I have been in a 4-person team where the daily meeting took 30 minutes and people often rehashed discussions they had on the previous day. I have also been on a 10-person team where the meeting took 10 minutes on a bad day
Oh totally seen it work myself but I don’t know that it was agile that worked as much as they had a kickass team.
Some teams just jive well. They communicate, they know what each other is doing, and they can plan with minimal waste. And when it’s successful that’s across all roles not just the devs.
In my opinion those teams would have succeeded in waterfall, kanban or their own home brewed strategy as well.
Oh totally seen it work myself but I don’t know that it was agile that worked as much as they had a kickass team.
Some teams just jive well. They communicate, they know what each other is doing, and they can plan with minimal waste. And when it’s successful that’s across all roles not just the devs.
In my opinion those teams would have succeeded in waterfall, kanban or their own home brewed strategy as well.
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.
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.
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.
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.
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 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.
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
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!
-
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
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
The big thing you can do from the command line is script it.
I don’t know, a tool we use at my work has a git GUI integrated, and it breaks all the time, lol.
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 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.
My point is, you won’t ever try. You’d only use “weak” variables inside the function you’re working on.
It’s explicit when you absolutely need it to be, when the function is being called and you need to know what arguments to pass and what it’ll return
A string being parsed as a date-time is presumably user input, which is potentially invalid.
When you say user, you mean a user of a function? In that case PHP would throw a TypeError, and presumably only happens when developing/testing.
If you mean in production, like when submitting a form, an Exception may be thrown. In which case you catch it and return some error message to the user saying the date string is invalid.
By “user” I mean the person who is using the application.
Using exceptions for handling unexceptional errors (like invalid user input) is a footgun. You don’t know when one might be raised, nor what type it will have, so you can easily forget to catch it and handle it properly, and then your app crashes.
you can easily forget to catch it and handle it properly
Even if I coded the form by hand and that happened, it’s on me, not on the programming language.
But I don’t, I use a framework which handles all that boilerplate validation for me.
Not everyone can or even should learn programming.
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.
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.
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.
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?
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.
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.
Yeah the error list is my friend. Typos, assigning something to the wrong thing or whatever is fixed without having to run the code to test it. Just check the error list and fix any dumb mistakes I made before even running the thing. And I can be confident in re-factoring, because renaming something is either going to work or give a compiler error, not some run-time error which might happen in production weeks later.
Even when you’re using a dynamically typed Lang you should be using all the appropriate scanners and linters, but so many projects just don’t.
I joined a large project half way through and I ran pylint and stared as the errors (not just style stuff) poured out…
I do believe that static typing is at least a local optimum, but I am still not entirely convinced. Rich Hickey is a very convincing presenter and I can’t help but think that he is on to something — with Clojure the chosen direction is contract-typing, which is basically a set of pre- and post-conditions for your functions that are evaluated at runtime. Sure, it has a cost and in the extremes they are pretty much the same as dependent types, but I think it is an interesting direction — why should my function be overly strict in accepting a “record” of only these fields?
It’s much easier to work with streams of untyped data in a weakly typed language.
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.
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.
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.
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.”
Yeah, I mean no shit, with hindsight it’s obvious they were looking for the 10/10 answer. I was kicking myself for days afterwards because that’s the only question I felt I answered “wrong”. Tech interviews are such a shit show though that you can start to overthink things as an interviewee. Also, an important aspect of the question that I didn’t mention was they specified “1 is completely new, and 10 is working at Microsoft on the .net framework itself”. The question caught me off guard. I have literally no idea what working at Microsoft on the framework is like. In that context being a 10/10 felt like being among the most knowledgeable person of c# of all time. Could I work on the framework itself? Idk maybe, I’ve never thought about it, I don’t even know what their day to day is. I should’ve just said 10/10 though, it was a dev II position to work on a web app, it wouldn’t have been that hard.
This take gets colder as you get more experience.
The mark of a true master.
Computer hardware has been getting faster and faster for decades at this point, but my computer still slows down. Like WTF. The dumbass programmers take the extra power given to them and squander it instead of optimizing their code. Microsoft word could run pretty well on a windows 98 PC, but the new Word can slow down PCs that are 5-10 years old. Programmers are complete idiots sometimes…
As someone who only learned a few things about programming, is optimizing code an easy thing? I’ve read about that many times but the only thing I could imagine (and I had to imagine it as I’m not really a programmer) is that perhaps their codes could be more efficient (so rewriting their code so that ten lines do the job of thirty for example) but I feel like if they lack the logic skills or math skills to do it then perhaps that’s why the code contains large functions and such.
But again, I’m not a coder, so I’ve no idea how in practice code can be optimized.
Shorter is usually faster so your right on that account but not always. There are few things like optimizing for cache hits that can vastly speed up programs but are hard to do. Most slow programs are due to technical debt, high dependencies usage, mixed with laziness and lack of interest in developers with speeding up their program.
I recommend https://www.youtube.com/watch?v=pW-SOdj4Kkk on this topic.
Here is an alternative Piped link(s): https://piped.video/watch?v=pW-SOdj4Kkk
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source, check me out at GitHub.
i hate to say itbut r u able to use linux ?Linux can be just as much of a slow-ass OS. The real issue is all of the crap everyone wants to do in the browser now.
With linux you have the option of debloating your system by using a minimalist distro with Windows you have no choice
