one million time this. as the resident tech lead I spend more time trying to get people focus on things that matters than actually designing and documenting
can provide daily anectodes but here's the last one: we use a javascript scrolling library, for reasons etc, long story short a programmer spent a couple day trying to figure out why the horizontal bar wronly showed on edge, until I went in and dropped a display none on the bar itself.
ultimately we aren't paid for technical excellence but for working programs.
> can provide daily anectodes but here's the last one: we use a javascript scrolling library, for reasons etc, long story short a programmer spent a couple day trying to figure out why the horizontal bar wronly showed on edge, until I went in and dropped a display none on the bar itself.
If that is something that has to be done a couple of times in a projects whole life, fine. If that is how bugs are solved all the time or frequently, I can only imagine how bad the codebase will be to maintain in years, and how depressing a job it must be to work on it.
That line of thought bleeds that no-one cares about the project, and only cares that the "people paying for it" hopefully don't notice the state of affairs underneath, and that they are not in a position to switch away from the product when ultimately it burns, which it will, if that is how bugs are treated. It bleeds that money is the only incentive, not heart, not passion, and that's just sad. It's why so much software is so bad and ends up costing much more in the long run than fixing the damn bugs properly right now, either because you end up having to maintain it until death, because it's so hard to maintain, or because you can't keep increasing customers after years because the product is now in such a bad state that time is spend fixing/hiding bugs instead of adding new features or improving existing ones.
> ultimately we aren't paid for technical excellence but for working programs.
That is true for most people and most projects, unfortunately. Bugs should not be covered and hidden away, they should be fixed.
I had the same reaction as you to this post, so thank you for nicely summarizing my thoughts.
I'll just add:
To me, the main distinction is this: you must at the very least figure out the reason for the unwanted behavior. If you don't, then you really have no idea whether your quick little fix covered up something important or not.
It's one thing to investigate, find out the cause, and then say "meh, that's way too expensive/time-consuming to fix, so we'll switch libraries/3rd party code or just remove the requirement for the special scrolling". It's quite another to just say "meh, display: none, look at how productive I am !".
I've had other developers do this in front of me, and it freaks me out to no end. One sat there and told me that if he changes a month calculation to subtract a month, then the total comes out correctly. I asked him why that was and he said "Why does it matter, I'm getting the right result ?"
We all need to remember that we're not being paid to type, we're being paid to think.
In a third party library which already touches a sensitive area that shouldn't messed with in the first place? That'd be a week of two of work, easy. Means reaching a client less. No way I'm gonna chase the white rabbit in its hole to fix something that has no side effects and zero ripercussion on other components.
> we use a javascript scrolling library, for reasons etc, long story short a programmer spent a couple day trying to figure out why the horizontal bar wronly showed on edge, until I went in and dropped a display none on the bar itself.
Wouldn't an even simpler solution be to just use the scrolling built into browsers?
Because while default scroll is fine for scrolling pages whole, in any scrollable div that's not top level it looks out of place like a blacksmith on an iceberg.
It's a gray slab that looks like a tombstone riding a straight, dull rollercoaster and unless your site makes a point of having a '90s inspirational look there's no way to integrate them in a page so that it doesn't feel completely detached.
If you need smooth scroll you can't rely on browser support and need to use a library or cook something up yourself. It's surprising how few browsers work with smooth scroll. Today it's basically only Firefox; not even Chrome.
Not to be a fanboy but I use a Mac and one of the things that they clearly did a huge amount of research and fine tuning on is the scrolling. I can always tell when there's non native scrolling on a site and it always sucks. Maybe I'm out of touch, but IMO the smoothness of the scrolling is an OS or hardware level feature. If somebody's OS or hardware does not scroll smoothly, then clearly it's something that they're used to from every other site they visit.
Putting a "smooth scrolling" library in makes about as much sense as rendering all of your site's text on canvas because some computers have font aliasing issues. It reeks of a micromanaging CEO getting fixated on some arbitrary requirement that makes stuff look better only on his computer.
I'm not talking about manually implementing a virtual scrollable canvas. I'm talking about "make item 19 in that list box visible in the middle of It's display area."
I agree that scrolling virtual spaces should be native and hardware accelerated whenever possible, but I think we are talking about different use cases.
Imagine there's a scrollable list of items and you want to scroll one particular item into view when some event happens. Without smooth scroll the item just pops into view and the user may not see it happening. It's a usability issue-- when the user interface jerks instantly, the user can lose context about what's happening. When it's smoothly animated it's easier for the user to keep track of what's happening in the user interface, and to see how one interaction triggers the next.
Done right, animation isn't just snazzy, it produces a more usable, more approachable user interface. It helps the user keep a good mental model of what's going on. It's easier for them to mentally track "ah, when I select this item, it also selects that other item in the other list".
It's the same reason why when you click an app on your phone it animates up from the app icon when the window opens. The animation wordlessly tells the user "I'm opening this app, and the window that's appearing is born of the icon you just clicked." Necessary? Not exactly. More natural? Absolutely. Nothing just snaps into existence in the real world, except for maybe things like lightning.
When things appear out of nowhere it can be jarring. Animation is especially called for when it might not be intuitive why you're making a change to the visual state, or when you want to call attention to something.
Keep in mind that a generation ago, pretty much every piece of software (even games!) came with a printed manual that the user needed to read first before expecting to be able to accomplish anything. Today users expect to be able to figure things out for themselves, and animation is part of the user experience that helps users learn their applications naturally by exploring the user interface.
Exactly, and just we wait for mainstream VR/AR. I believe we'll see quite a lot of animation skeumorphism (is that a thing? I mean realistic animation/appearance relatively to a real world setting, e.g. gravity on objects, diffraction on transparency, etc). For a few years at least, time for users to learn new interaction paradigms and positioning within a virtual/hybrid environment.
This is what I use right now for cross-browser smooth scrolling. It's native first with a jQuery fallback.
<style>
html, body {
scroll-behavior: smooth;
}
</style>
<script>
// Uses native smooth scrolling if available, otherwise uses a jQuery fallback
// Just add data-scroll attribute to any anchor you want to make smooth
// Add data-scroll-header to a sticky nav / header to offset the window top
if (!('scrollBehavior' in document.documentElement.style)) {
// jQuery fallback
// Taken from https://css-tricks.com/snippets/jquery/smooth-scrolling/
$('[data-scroll]').click(function() {
if (location.pathname.replace(/^\//,'') == this.pathname.replace(/^\//,'') && location.hostname == this.hostname) {
var target = $(this.hash);
target = target.length ? target : $('[name=' + this.hash.slice(1) +']');
if (target.length) {
$('html, body').animate({
scrollTop: target.offset().top - $('[data-scroll-header]').height()
}, 600);
return false;
}
}
});
}
</script>
> ultimately we aren't paid for technical excellence but for working programs
In my very un-expert opinion, there has to be a balance between technical excellence and working program.
I'm assuming that your case is really a non-issue. A dev wanted to find the root cause of the issue, fix the issue, and then never have to worry about it again. That's an admirable quality to me, but from your quick fix, it proved to be too much overhead for so little gain.
On the other hand, you can reach a point such that you peel back a Band-Aid brand adhesive bandage, you find a generic brand adhesive bandage atop a goopy dollop of ointment atop rotting wounds. I think technical excellence is knowing when a quick-fix for your situation is good enough and knowing when you really need to roll back the sleeves to dive in.
> ultimately we aren't paid for technical excellence but for working programs.
Depends who you are, now doesn't it? People writing core OS components, network infrastructure, cloud servides, etc have a much higher bar to hold to.
But I'm in agreement with antirez that good design and solid technical underpinnings often make projects go much faster. Even if you don't know it by heart, being able to research the tools you need can give better results than not knowing at all.
ultimately we aren't paid for technical excellence but for working programs.
Some level of technical excellence is required, though, otherwise complex technical debt piles up, and we are then no longer able to deliver working programs.
can provide daily anectodes but here's the last one: we use a javascript scrolling library, for reasons etc, long story short a programmer spent a couple day trying to figure out why the horizontal bar wronly showed on edge, until I went in and dropped a display none on the bar itself.
ultimately we aren't paid for technical excellence but for working programs.