Git: It took me a while to learn the basics, and it's still something I don't feel like an advanced user of. I tend to stick to the commands I'm most comfortable with.
Testing: This took a while for me to get the hang of, but I feel like it's turned into a strength. I love TDD and find great comfort in a well-written regression test. 😅
Typed languages: I think I got into the domains of untyped languages as a career because I had some mental blocks around types. These days I'm much more comfortable in either domain, but happen to still work mostly with Ruby, my fave lang.
I’m currently working on two open-source projects: Fugu (https://fugu.lol), a privacy-friendly product analytics software, and Mapzy (https://mapzy.io), a store finder.
Same with testing. Used to hate it, now can't sleep well at night if I deploy untested code. Also, the green check marks have something oddly satisfying. Have you ever used RBS or Sorbet with Ruby?
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
When I get lost in my programming of a library, for example, because there are so many ways to implement its features and so many plans for features, I then start to ask myself: how I can simplify things or get something useful implemented more quickly? Then I act like the user of the library by writing unit tests about how I want to interact with it to access its features, before they are done. This in turn forces me to tie down the library by programming it to match the desired usage, and reduces frustration by fast-tracking a workable solution in a pragmatic manner. It's specing out the solution in parallel with implementing it, instead of having it speced out fully beforehand and following up with implementation only afterwards.
TDD for the sake of itself isn't necessarily useful, until you find a reason that it helps you in your line of programming. Not all lines of development need TDD like user interfaces that are more driven by design specs and implemented using an event system, as one example.
I believe to test out a concepts, we do clone a repo and test it out if it worksout push it or bail out. Critical scenarios is when you do force push on remote branch and working with remote repo.
I think testing/TDD is one of the topics people struggle with the most ... not to understand the theory, but to practice what "we" preach, and to stick with it ... it's THE first thing people (including myself) tend to drop, or get sloppy with, when push comes to shove.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Why not the git CLI ? I've hardly ever used anything else (apart from some basic git tooling in VSCode to view diffs and git history), and I've always been happy with it. Whence the advice NOT to learn it?
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Maybe, but for me learning and using the CLI was/is the easiest way ... I've tried to use a GUI a couple of times, but pretty much disliked it.
The CLI (i.e. text based commands) also allows me to script, document and google what I do ... making it all much more repeatable and "discoverable" than when I have to click around in a GUI. Anyway I've always loved and preferred the command line :)
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
A simple terminal UI for git commands, written in Go with the gocui library.
Sponsors
Maintenance of this project is made possible by all the contributors and sponsors. If you'd like to sponsor this project and have your avatar or company logo appear below click here. 💙
Elevator Pitch
Rant time: You've heard it before, git is powerful, but what good is that power when everything is so damn hard to do? Interactive rebasing requires you to edit a goddamn TODO file in your editor? Are you kidding me? To stage part of a file you need to use a command line program to step through each hunk and if a hunk can't be split down any further but contains code you don't want to stage, you have to edit an arcane patch file by hand? Are you KIDDING me?! Sometimes you get asked to stash…
Ah I misunderstood that ... okay, added this to my ever-growing list of "things I should check out" - but in all likelihood I probably won't, and I'll stick to my current workflow instead, as I'm used to it and it seems adequate to me - and since I'm, well, a bit too "lazy" ;) to adopt an "entirely new way" ... tradeoffs, always tradeoffs.
(I do acknowledge that, once I've learned it, I MIGHT become marginally more productive - but I'm probably better off eliminating a few far worse sources of unproductivity among my current working habits)
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
My question then would be: how much time did it really took you to learn to do git without bad mistakes all usually during many years?
For me I realized it was much much more that I would have needed to learn lazygit once I understood the git concepts.
That's why I tell people that they should feel free to not learn the details of git if they have better things to do with their life. Like I learned all vim commands when I was young and it was fun but no one should feel obligated to do the same.
"How much time did it really took you to learn to do git without bad mistakes all over the years?"
The honest answer is, not much ... I'm absolutely not saying I'm more clever than the average dev, but maybe I'm more pragmatic. I learned the basics and that was pretty simple, and the number of errors or screw-ups has been tiny over the years.
Note that I've always steered clear of "advanced" stuff like git rebase, when a "merge" does the job as well, I just keep it simple and it works for me. Less than a dozen commands that I'm using on a daily basis (I tend to define bash aliases for most of them), and on the rare occasion when it gets hairy I google it.
Not feeling like I've ever missed anything, git is simple and logical, a breath of fresh air and a huge relief when you've had to work with stuff like CVS or Subversion (or, the lord forbid, MS SourceSafe).
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
I can't really comment on that in a knowledgeable and objective way, but the ones I know and have worked with don't really seem to have the problem, AFAIK ... could be wrong tho :)
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
The easiest way to know is to look at how much traffic super basic git questions that shouldn't be an issue get on stackoverflow. That's the equivalent of a code smell but for a product
Look, what I know has been criticized a lot is that some of the commands aren't intuitive - I mean, when I want to discard my local changes, why on earth do I need to type git reset HEAD . ?
But personally that has never bothered me, it was part of the learning curve, and not even the most complex part by far. In some cases I've even tucked it away behind a bash alias.
I wanna discard my local changes? I press Control-R in my bash shell and type "reset" and bada bing bada boom there's my git reset HEAD . and I press ENTER, done.
Does-not-bother-me-at-all.
Oh and more recent versions of the git client have rationalized a few commands by introducing more logically named new variants.
The thing I appreciate about git is the sheer genius of how it's designed and how it works, the commands are just that, it's never bothered me.
Personally I'm just the type of guy who wants to work with "the thing" itself - 'bare metal' if you like. I don't want wrappers or GUIs or whatever stuff needs to be put on top of it, and being dependent on that.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
I'll go first with a few:
Thank for your writing. Wonderful
Same with testing. Used to hate it, now can't sleep well at night if I deploy untested code. Also, the green check marks have something oddly satisfying. Have you ever used RBS or Sorbet with Ruby?
Javascript. . .still javascript. What I'd give to understand it!
I mean, JavaScript is just lots of concepts. What are you having trouble understanding?
Do you have any suggestions for how to learn TDD? I can't seem to grasp it.
The most awesome way to learn TDD is to do a pair-programming/mob-programming session where you strictly divide the responsabilities
I should add that I think that TDD should be one strategy that you have in your toolbox and not a dogma.
When I get lost in my programming of a library, for example, because there are so many ways to implement its features and so many plans for features, I then start to ask myself: how I can simplify things or get something useful implemented more quickly? Then I act like the user of the library by writing unit tests about how I want to interact with it to access its features, before they are done. This in turn forces me to tie down the library by programming it to match the desired usage, and reduces frustration by fast-tracking a workable solution in a pragmatic manner. It's specing out the solution in parallel with implementing it, instead of having it speced out fully beforehand and following up with implementation only afterwards.
TDD for the sake of itself isn't necessarily useful, until you find a reason that it helps you in your line of programming. Not all lines of development need TDD like user interfaces that are more driven by design specs and implemented using an event system, as one example.
I started my programming with Java, so typing wasn't a problem 🤣
I believe to test out a concepts, we do clone a repo and test it out if it worksout push it or bail out. Critical scenarios is when you do force push on remote branch and working with remote repo.
I feel the same way about git
I think testing/TDD is one of the topics people struggle with the most ... not to understand the theory, but to practice what "we" preach, and to stick with it ... it's THE first thing people (including myself) tend to drop, or get sloppy with, when push comes to shove.
As a lazy programmer, I don't fear to give the advice we are not supposed to give:
More details here:
Can beginners make a simple but meaningful contribution? Some unconventional advice #hacktoberfest
Jean-Michel Fayard 🇫🇷🇩🇪🇬🇧🇪🇸🇨🇴 ・ Oct 1 ・ 7 min read
Why not the git CLI ? I've hardly ever used anything else (apart from some basic git tooling in VSCode to view diffs and git history), and I've always been happy with it. Whence the advice NOT to learn it?
Laziness, the reason is Laziness.
I prefer to use tools that
Try to read
man git-logand you will understand what I meanMaybe, but for me learning and using the CLI was/is the easiest way ... I've tried to use a GUI a couple of times, but pretty much disliked it.
The CLI (i.e. text based commands) also allows me to script, document and google what I do ... making it all much more repeatable and "discoverable" than when I have to click around in a GUI. Anyway I've always loved and preferred the command line :)
Lazygit is not a gui, it works in the terminal, give it a try
simple terminal UI for git commands
A simple terminal UI for git commands, written in Go with the gocui library.
Sponsors
Maintenance of this project is made possible by all the contributors and sponsors. If you'd like to sponsor this project and have your avatar or company logo appear below click here.💙
Elevator Pitch
Rant time: You've heard it before, git is powerful, but what good is that power when everything is so damn hard to do? Interactive rebasing requires you to edit a goddamn TODO file in your editor? Are you kidding me? To stage part of a file you need to use a command line program to step through each hunk and if a hunk can't be split down any further but contains code you don't want to stage, you have to edit an arcane patch file by hand? Are you KIDDING me?! Sometimes you get asked to stash…
Ah I misunderstood that ... okay, added this to my ever-growing list of "things I should check out" - but in all likelihood I probably won't, and I'll stick to my current workflow instead, as I'm used to it and it seems adequate to me - and since I'm, well, a bit too "lazy" ;) to adopt an "entirely new way" ... tradeoffs, always tradeoffs.
(I do acknowledge that, once I've learned it, I MIGHT become marginally more productive - but I'm probably better off eliminating a few far worse sources of unproductivity among my current working habits)
My question then would be: how much time did it really took you to learn to do git without bad mistakes all usually during many years?
For me I realized it was much much more that I would have needed to learn
lazygitonce I understood the git concepts.That's why I tell people that they should feel free to not learn the details of
gitif they have better things to do with their life. Like I learned allvimcommands when I was young and it was fun but no one should feel obligated to do the same."How much time did it really took you to learn to do git without bad mistakes all over the years?"
The honest answer is, not much ... I'm absolutely not saying I'm more clever than the average dev, but maybe I'm more pragmatic. I learned the basics and that was pretty simple, and the number of errors or screw-ups has been tiny over the years.
Note that I've always steered clear of "advanced" stuff like git rebase, when a "merge" does the job as well, I just keep it simple and it works for me. Less than a dozen commands that I'm using on a daily basis (I tend to define bash aliases for most of them), and on the rare occasion when it gets hairy I google it.
Not feeling like I've ever missed anything, git is simple and logical, a breath of fresh air and a huge relief when you've had to work with stuff like CVS or Subversion (or, the lord forbid, MS SourceSafe).
Then if isn't broken don't fix it.
That's what I mean :)
Yes, and what I mean is that I think it's broken* for many more developers than you probably think.
(*) meaning here that it technically works but it requires way much efforts than necessary
I can't really comment on that in a knowledgeable and objective way, but the ones I know and have worked with don't really seem to have the problem, AFAIK ... could be wrong tho :)
The easiest way to know is to look at how much traffic super basic git questions that shouldn't be an issue get on stackoverflow. That's the equivalent of a code smell but for a product
stackoverflow.com/questions/tagged...
Look, what I know has been criticized a lot is that some of the commands aren't intuitive - I mean, when I want to discard my local changes, why on earth do I need to type
git reset HEAD .?But personally that has never bothered me, it was part of the learning curve, and not even the most complex part by far. In some cases I've even tucked it away behind a bash alias.
I wanna discard my local changes? I press Control-R in my bash shell and type "reset" and bada bing bada boom there's my
git reset HEAD .and I press ENTER, done.Does-not-bother-me-at-all.
Oh and more recent versions of the git client have rationalized a few commands by introducing more logically named new variants.
The thing I appreciate about git is the sheer genius of how it's designed and how it works, the commands are just that, it's never bothered me.
Personally I'm just the type of guy who wants to work with "the thing" itself - 'bare metal' if you like. I don't want wrappers or GUIs or whatever stuff needs to be put on top of it, and being dependent on that.
I should do an article about this.
Lol I'm the opposite. Untyped languages drive me nuts.