Let's say you work independently and you get by, but maybe you're a little afraid that if someone were looking over your shoulder you might be exposed — even if you're a senior dev?
What coding concept or practice seem commonly understood, but you never learned?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (78)
git rebase— I barely understand how to use it, and really hope nothing goes wrong.Imagine a literal tree 🌲 like that.
Now get a saw and cut a branch off
Next change the colour of the leaves of this branch to purple 💜
Next take your glue and climb up 🌲 the tree, and stick it right on the tip.
Where you cut the branch off, go there and paint some bark over it like it never happened but actually pretend it was always at the top
The base is the tree branch
You are re base ing the branch at the top of the tree, I think of it as magical time travel
Except that this picture explains nothing to me about what happens. It begs questions:
You see the confusion I (and I expect many) have around rebase is not the nice imagery of what it means (moving a branch somewhere else) it's the devil of the detail, about what happens to the changes between the point of divergence and the tip of both the branch being rebased and the place it's being rebased to.
For simplicity's sake, you can consider a commit a diff to the commit before it (called the "parent"). How git actually works under the hood is a fair bit more complicated (it actually stores blob data of specific states), but that's the surface-level workings.
When you merge, you're creating a new commit that applies the necessary changes to the two commits that are being merged together (the target branch's current commit, as well as the source branch's current commit). Here, again for simplicity's sake, you can consider that merge commit to be two diffs, one on either side, which produce the new merged state.
Rebase instead takes the diffs from the oldest divergence between the two branches, and moves them onto the current commit of the target branch. For that, it applies the same diff onto the current commit as its new parent (instead of whatever was the original parent), changing (ideally) only the parent relationship of the commit.
Thus, where a merge maintains two different routes which converge in the merge commit, the rebase maintains only one route to the same target state. This means that either of the merge commit's parents have their own parents until they reach back to the divergence, whereas the rebased branch only has a single line of parentage going first to the other branch's most-recent commit, which itself then has the parentage back to the original point of divergence (which is now no longer related to the rebased branch directly at all).
So where merge glues two sticks together in parallel, the rebase glues them together in sequence.
Edit: re what the actual differences are after-the-fact, operationally: if you go back to an earlier commit, it will only follow its own parent relationships. So if you check out a commit specifically on either of the merged branches, you won't have the changes from the other branch. As for conflicts, you do indeed get them either way, though rebase makes it a tad easier to ensure that an individual commit is consistent and can, for example, compile correctly for the expected state at the time. Rebase often cuts the conflicts into smaller chunks that are somewhat time-coded to the commit it is currently working on, before moving to the next in the rebase chain.
I appreciate your wanting to get technical and I do see your point of view, but my little story is for people who have literally no idea what to think about rebasing, it's what I think about it and I do it all the time with no major fires for almost 5 years of rebasing 🔥🚒🚨. The details you crave and I suspect may know, are best learned / shown not told. Like can you describe an interactive rebase? It's not very easy on paper or in a comment text box ☺️
What I would say is that it offers a jumping off point to allow people to talk about things they would otherwise not know how to find the words
Thanks for helping FJones!
Was slightly confused there for a minute, thought the other comment was directed at me :D
DEV still can't handle deep threads too well.
It confuses me too 🤣
Love it. Thanks.
Your most welcome, of course as it's been highlighted it's more complex than said but I think that's need to know
The relevant usages are pretty rare and
rebasecan be risky, so, in doubt, not using it might be wiser.It's not uncommon to set it as a global pull strategy (which is the same as
git pull --rebase) to prevent useless merges of the same branch in the git history every time you pull the remote branch for updates (e.g., "merge master into master").However, I would not recommend
git rebasebetween different branches unless you perfectly know what you're doing (e.g.git rebase master develop). Otherwise, it can turn really nasty. I've already seen it, really hard to resolve.I find the interactive rebase
git rebase -imore helpful and less risky provided you use it only locally BEFORE pushing anything to the remote. It allows reorganizing and editing commits, which can improve readability.I'm not sure anyone understands
git rebase. Every single time someone mentions it I am back to the tutorial pages and it'll cost me some minutes of reading before, if I'm lucky I go "a ha, I think I get that".Lol that's one I have to look up EVERY time to understand how it works again ... used it a few times, once it went horribly wrong, not using it anymore every since ... plain "git merge" is your friend!
Raise your hand if you only use print statements for debugging.
Debugging tools — not even once.
I admit, I do use that from time to time, only if the "normal" way of debugging is out of the question. But a debugger can really be of help, if you can step through code you didn't write for example. Then you understand what flow the program does and why "x" is suddenly 4. or when you can immediately go to the function with line where the error occurred, and start your investigation from there.
(A stack-trace might be helpful too, and some debuggers do share this info with you)
Nah, browser debugging tools are your friend. Just plain awesome.
Present, sir.
glad i am not alone
For me that's only the case for Javascript debugging - any other language that I use, I don't have an issue using a debugger.
🤚
Estimation 😭
He said "commonly understood" not "entirely impossible." 🙃
I wouldn't worry too much about that. It's not worth doing, a total waste of time
Yeah, like you want a house to be build and pay them by the day. How long is it going to take.
"we don't know" is not a valid answer. Estimation is very handy in order to start the process, or not.
When was the last time you had a remotely reliable estimate from a builder? 😂
Estimation is always a bit of a challenge because you might need to do something you've never done before. So estimating that is based on your own experience.Which can be hard if you have never done something before. But based on what you have done can be helpful in finding out a rough estimation, which is of course better than saying that you don't know.
Look for known facts:
You (don't) know
Give all of these a score. based on that score, give an estimation, but with the context why you came to that score / estimation.
If it still is hard, see if you can slice it into smaller pieces and do this piece by piece.
But in the end it's an estimation, right? So if you deliver in that time, should not be the question.
Also, estimate for yourself, if you have 10% or 25% ready. Then multiply that to a 100%. Keep track of the next 10% or 25% and see if you're still on schema. If not, tell and adjust your estimation. (and so it becomes more accurate in the end, but also along the way).
Good luck :-)
Oh, there's a lot of things I'd be uncomfortable with doing, if someone were looking over my shoulder:
tail,chmod,ps,grepetcIf someone is staring at my screen when I'm doing the above, the pressure to not make mistakes can be overwhelming. 😅
Oh man, +1 on the CLI – my array of terminal commands is pretty limited.
Regex - beyond the really basic ones I have to look them up EVERY time - in practice when there's a simple way to do a task without a regex, I'll do so ...
Totally Agree! Especially when it is your Nerd Sibling aka Brother/Sister
Personally, having worked from home for years now — there are a lot of things you just only learn when in a physical space with people.
Examples?
How to make small talk
Dependency injection. It always rubbed me the wrong way.
Yeah, I understand the basic concept of passing dependencies in as a parameter, but the frameworks for doing that are always too magic for my taste.
Exactly how I feel. I know how to use it, but it feels............ wrong.
it is a good way of not hard-wiring dependencies into parts of the code.
That code should work independently, which makes testing far less complex.
To explain it a bit more:
we want to travel so we take a vehicle to do that.
the vehicle should be able to steer, break and so on.
As a dependency, I give it a car to work with, and the vehicle is now a car and does satisfy its needs, but a plane, a truck, a bike etc. also can do that.
To actually test the software for "the break()" function, you can feed it a mocked-vehicle, that will help you in testing the behaviour. But you can also choose to have a "real" vehicle, up to you.
But if you wrote it by just accepting a car, then that's all it can work with.
SOLID, specifically the "L", implies that a function that requires a "vehicle" must work with cars, bikes, and planes without breaking the application. Dependency injection is not needed.
Amen
same too
Caching. When's it automatic, when do I invalidate it myself, why is this asset not refreshing, what are all these cache headers, something something redis??
Oh man, caching is bad because every layer of the stack uses it in some way, so people use the same word to refer to a lot of different things happening.
It's a general-purpose computer science-y idea, so it would make sense that it's used in a lot of places, but then in web dev we generally mean very specific things in different contexts as well.
So yeah, it's a thing.
I installed a bunch of starter plug-ins in my editor when I first got started and haven't added another one since. I'm pretty sure I'm doing some stuff really unproductively. My flow works, but I'm pretty sure I'm doing it wrong.
The last time I encountered this type of question it was around 100% Code Coverage.
I had several years of exposures to tests but our team and products didn't fully embrace the strategy; I wasn't seeing the value in terms of code quality, rather just a check that what you wrote isn't broken upon a later revision.
After our company was acquired, the new engineering org embraced a standard of 100% code coverage. That is a very high bar, and we do allow exceptions, but overall the team has been able to meet that standard with ease.
With our projects having 100% code coverage, we saw improvements in Frequency of Deployments, Lead Time for Changes, MTTR, and Change Failure Rate (Read the book Accelerate if you're unfamiliar with these metrics), ultimately allowing us to build a product at scale - in terms of collaborators (~50 engineers) and deployment stability/consistency.
Unfortunately, 100% code coverage doesn't say much if done the wrong way.
We aim as high as possible, but the complex code before the simple code.
And anything added should be covered by a test.
Read the book I reference in the original comment, if your engineering org adopts those practices, 100% code coverage makes a significant difference.
Which book is that. Tried to find you book reference, but can't find it.
BTW: if we write a test for a simple getter (or for generated code for that matter), that will be the day that all other significant tests are written :-)
Accelerate
redux in react
All the files needed is confusing indeed. Take a look at Redux Toolkit. I find it much simpler to use. Still not super easy, but better.
Most of the time I find the Context API to be enough. That said I used Redux Toolkit once and it was pretty cool