Well, what's wrong with code being incomplete at some point of time?
Is it not waterfall enough? Is it too much learning from customers? Is it too small PRs of duration less than 1-6 months? Is it not enough premature optimization?
That's kinda unrealistic.
It's okay to expect that if you change the requirements for A, there should be no changes in the code of B.
It's not okay to expect that if you change the requirements for B, then there should be no changes in the code of B.
For essentially all my projects, I end up having most of my business logic at the trunk of the project source. The leaf nodes are the most general purpose modules (e.g. database clients, utility functions), the branches are still relatively generic but closer to the business domain. The trunk (e.g. entry point of my program) changes very frequently and is directly related to the business domain. The branches change rarely and the leaves almost never change. The leaves are usually third-party modules. For the leaves, I will typically swap them out if they cease to meet my requirements. I almost never refactor those. For the branches, I sometimes have to refactor 1 or 2 of them at most. I can't recall ever doing a refactoring which touched on many branches at the same time.
Most of my refactoring only affect the trunk of the code. I try to have all the business logic for a program or service represented in a single file. If the file gets too big, I create new modules 'branches' and move the most generic logic to those branches. My top level file tells the full story of the program/service. Anyone can open that file and, based on the module names and method names that are being called, they can figure out what happens and when. All the events, endpoints, logging, access control and other externally observable behavior is wired together in that file.
If the file has been abstracted to the maximum amount possible (with all generic functionality moved to branch modules) and it's still too big, it may be time to switch to a micro-service architecture. Break up the trunk into 2 parts and we basically end up with 2 apps/services. This rarely happens though. With the right level of abstraction, you can fit a massive amount of user functionality in a single main file. By the time the main file's code becomes overwhelming, the application's UX becomes overwhelming for the end user too... Time to split up into multiple apps.
Think of how complicated UX would be if a video-editing software tried to support image editing as well (e.g. to make fancy title screens or UI overlays). It would become too much for the user. Just make two different applications; one for video editing, one of the image editing. You can integrate them in a seamless way, but they should be different apps.
This long comment doesn't contradict my point because "The trunk ... changes very frequently". Requirements change, and thus, code changes. There is nothing you can do about it. It's cool when everything is modularized enough that you never need to change some parts of the code. But it doesn't mean those parts of the code are better than code that changes often.
Now, if you think a little more about this, there is a huge risk that some of your leaf code should be in a library. For example, SQL builders, ORMs, UI kits, markdown formatters, etc. When it's a publicly available package used by many devs around the world, the code in it often changes. The reason why your leaf code doesn't change is that you don't have a proper investment return for small changes because you are a single user. Code in libraries handles more useful use cases, it handles more edge cases, it provides better API, and it contains fewer bugs than code in leaf nodes. And all that's while code in libraries is constantly changed. And code in leaf nodes... I would say that the proper description for it is "used, but dead".
Are you trying to defend a software engineer who is bad at writing readable code by... bringing Knuth to the table?
The same Knuth who published "Literate Programming"? "Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do"?
I have worked with people that have a command of a given programming language, and algorithms such that it appears to be magic to me. (C++ is common for this problem).
So we share personal experiences now; okay, let me share mine.
Once, one of my teammates committed an extremely complex piece of code that I wasn't able to understand. As I expected, we soon started to start bug reports. Finally, the original author couldn't fix it properly, so I threw away the code and rewrote it from scratch. I made it simple, readable, and, what's more important - debuggable. And it was correct.
So what? Your personal experience says that you are not the smartest person in the world, and my personal experience says that magic is magic — it doesn't work properly in the real world.
It's easy to build "magic" code that's hard to understand. You can just run any readable piece of code through an obfuscator. Still, no one believes that an obfuscator is genius. If you see "magic" code that, for some reason, truly works, it means that the author did a ton of research and forgot to put that into comments — i.e., obfuscated a code. If, even with comments, it still looks like magic, then the author avoided doing a self-review & simplification of the code. And well, sometimes, even after that, code can still be magic... if we have chosen the wrong tool for doing the job (does it sound like a depiction of genius?).
Well, for Ctrl+F there is sometimes a reason. Many websites uses technique called virtualization of lists. That boosts performance, but standard Ctrl+F doesn't works anymore properly
I know of 2 websites that do this.
1. Confluence
It's super annoying and takes up a lot of screen space
2. Nexus
It simply kills it. You can use ctrl-f but it simply will not find text right in front of you..
DOS emulator and Vim emulator, and that's almost all I can imagine. Maybe games that would use the control key as an additional input---but in the browser???
There are so much changes for the last 15 years. You don't need to learn all that path. You need to learn modern web development from scratch, ignoring history.
Right now, modern web development is:
- Yarn/PNPM as package manager
- TypeScript as a programming language
- React as UI framework/library
- React Router for navigating multiple pages
- UI kit (I personally have good experience with React Material UI - https://mui.com/; there is also https://tanstack.com/)
- Something to deal with fetching data (tanstack query client is cool, provides caching out of the box)
- Something to deal with forms if you have that
- Maybe a store for managing data when it's too complex (see https://redux-toolkit.js.org/api/createSlice)
- And ofc, there are some templates/frameworks that bring something of that together (https://create-react-app.dev/; maybe https://vitejs.dev/) - google for templates.
I recommend finding some friend with modern experience or at least some youtube tutorials or at least some learning course. That would help you to catch up on the best way to bootstrap your first project. Then you can practice.
Because understanding of CSS doesn't helps you in the most cases.
Just return to the ages when we needed to support Chrome+Safari+Firefox+IE+custom mobile browsers (it wasn't long ago). All those engines had so many bugs. Understanding CSS won't help you deal with cross-browser compatibility. This is why we have things like caniuse.com and autoprefixer.
Go a little more back in time. CSS doesn't have a lot of capabilities. Some things can't be achieved at all. Other things can be done quickly via mix of CSS and JS code to update layout; otherwise you need to spend a week to achieve something worse with pure CSS. Even now, we have things like react-motion, react-transition-group - libraries to solve cases that CSS transitions&animations can't solve. (Should we talk about DND?)
In past CSS didn't had Flex-layout widely adopted. This is why there were JS libraries solving layout stuff. We still have libraries that provide list virtualization. Even with the CSS `contain` property (which arrived in 2017 and wasn't widely adopted even in 2021), working with DOM is not cheap.
We didn't have calc() and CSS variables. We still don't have CSS nesting widely adopted. This is why we have LESS & SASS. (Should we talk about CSS modules?)
And ofc, CSS is pretty useless for quick prototyping, you need a UI kit. UI kit means a conceptually different approach than using raw CSS - you don't need to do CSS a lot, but you need to learn UI kit a lot.
Finally, if you are building a product, you deal not only with styling. It's not a landing page, it's not a one week hobbie project -> you need to code a lot. If you are bad at styling, you are bad at ~10% (maybe ~20%) of your work. And considering all the things that we said before, if you are bad at understanding CSS, you are bad at ~1% of your work.
To sum up. You can make beautiful products with little CSS knowledge because CSS alone is useless.
Yes, but how much extra layers and computing power do you need? Of course, phonetic tokens are awkward idea, but there is a reason why word "human" is encoded as only one token.
Eight years of commerce experience. Nerd with various areas of interest in IT. I started as a naive coder with an algorithmic background. Now I'm able to build a product using only high-level vision. Still love to dig into technologies internals.
Eight years of commerce experience. Nerd with various areas of interest in IT. I started as a naive coder with an algorithmic background. Now I'm able to build a product using only high-level vision. Still love to dig into technologies internals.
Is it not waterfall enough? Is it too much learning from customers? Is it too small PRs of duration less than 1-6 months? Is it not enough premature optimization?