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.
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.
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.
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.
Refactoring 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.
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.
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.
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.
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.
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.
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
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!
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.
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.
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.
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.
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 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?
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.
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”.
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.
Honestly, I don’t think unit tests are a useful name. Everyone has a different idea of what a unit is and the line between unit tests and integrations tests is IMO not very useful. As long as your tests are
isolated from external factors (ie they completely control the test environment),
fast to run
repeatable, aka not flaky
can identify problems easily
Then where you draw the line between unit and integration is meaningless. It was meant to be that ingratiation tests were slow, so you wanted to shrink them down to make them faster to run. But I have not had a problem with the speed of more integration style tests in a long time.
I also don’t think interacting with the OS is such a bad idea. For instance the filesystem (what everyone always points to as an example) IMO is fine if done right. The big issue with interacting with the FS is keeping your tests isolated - too many people end up reading/writing the same file locations and thus breaking isolation. But you can always create a unique tmp dir for each test and do what ever you want inside that. Interacting with the filesystem on modern system is fast, and reliable - especially given that tmp locations are generally in ram these days.
I think the better term you are looking for is mocks and mocking. IMO these should be kept to a minimum. Like the above - you dont need to mock out the filesystem API when you can just use the filesystem in an isolated way. Same with network services - I really like gos httptest module, it lets you easily spin up a webserver that you can respond with whatever you need to. No need to create a mockable API when you can spin up a fast and reliable http endpoint to respond how you need it to.
Which leads to fakes (ie fake, simple implementations of a real external API). IMO these are far more useful than mocks and should be your first resort with mocks being your last resort. Such as things like gofakes3 an in memory s3 implementation in go that you can use any s3 client to talk to. Things like this let you create tests that you spin up the server (a unique one for each test), put objects into it to set things up how you need them, run your function and assert the contents are what you expect. Makes your tests more complete (and that you are not just testing your mock implementation rather than your actual logic) while keeping them isolated and fast - all the benefits of a small unit test combined with the wider scope of an integration test.
Couldn’t agree more with this comment and the thread in general, it’s a relief to see. I get so frustrated as so many of my colleagues seem to cling to this very old concept of the testing pyramid and associated definitions. It’s completely meaningless in a modern setting. We should mock as little and as far back as possible, yet others seem to delight in locking huge chunks of functionally out of the test base just ‘because’.
I believe we should have a new word that differentiates between ultra-basic tiny unit tests, and bigger unit tests that are still not integration tests.
E.g. rust and some other newer languages have a way to write basically an inline test for a function — that would constitute my former category. These make sense during development as a reality check. “Yes, this ad hoc stack I need inside this class should have two elements if I push two elems” sort of thing. That implementation may not even be accessible from the outside in case of an OOP language so you can’t even properly test it. Also, these are the ones that should change with the code and removing them is no big deal.
The other kind should work against the public APIs of libs/classes and they should not be rewritten on internal changes at all.
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.
Ruby does that (well you use the keyword “end” instead of a bracket) but it fell out of favor before it got as big as python, to my knowledge, because of worse multithreaded performance in comparison (which I think has been fixed) and a bias towards unix systems over windows
Front end and back end are different enough that you can really specialize in one or the other. They take very different mindsets. I know how to make css obey, I don’t know how to make sql performant. Its possible to have both, but not as well.
For every front-end dev, you need 3 back-end guys and a designer.
Programmers are not bad at our jobs, its just not a mature disclipline yet.
I don’t agree and I don’t disagree, but I thinkcontext matters a lot here. Some teams and codebases need deep knowledge, some don’t. Some nned sql performance, some don’t. Your conclusion is only true some of the time
Programming is over 70 years old, that’s not a new discipline. Yet, the engineering in our industry is still abysmal. Countless reinvented wheels, nothing is ever finished, changes happen often enough for the sake of change, not progress.
That’s part of the nature of programming. Half-finished might be good enough. If you’ve made an awesome wheel but I need a kink in one of my spokes and yours doesn’t do that, making my own wheel might be cheaper than modding yours.
OTOH, there’s nothing more frustrating than looking for a particular wheel, finding ten really great ones that collectively have the features you need, but individually aren’t good enough.
To stay in the analogy: usually we just want to transport things from a to b. It doesn’t matter, how we get there. So usually we begin with a road and start to cobble together a vehicle from barely fitting and functioning junk we find on the roadside.
There’s hardly any stable surface to work on. And that’s extremely costly.
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, but that was wrong. JavaScript is fine, C# is fine … as long as you don’t stop there.
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.
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.
“Unintuitive” often suggests that there’s something wrong with the language in a global sense
I mean only if you consider “Intuition” to be some monolithic, static thing that’s also identical for everyone. Everyone has their own intuition, and their intuition changes over time. Intuition is akin to an opinion - it’s built up based on your own past experiences.
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.
I don’t think it’s that deep. All people mean when they say it is that “[thing] defied my expectation/prior experience”. It’s like saying “sea food tastes bad”. There’s an implicit “to me” at the end, it’s obvious i’m not saying “sea food factually tastes bad, and anyone who says they like it is wrong or lying”.
You could say that about anything. Of course you have to learn something the first time and it’s “unintuitive” then. Intuition is literally an expectation based on prior experience.
Intuitive patterns exist in programming languages. For example, most conditionals are denoted with “if”, “else”, and “while”. You would find it intuitive if a new programming language adhered to that. You’d find it unintuitive if the conditionals were denoted with “dnwwkcoeo”, “wowpekg cneo”, and “coebemal”.
But there are languages that require varying degrees of effort to become natural. Something like Malbolge will pretty much neber be natural while something like Python can become natural to you in a few days.
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.
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++.
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.
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.
I started my career as C# dev and thought highly of Java because it’s what C# is ripping off of. Then I actually tried writing Java and had a new found appreciation for C#. This was over 10 years ago though.
Add comment