10 ms·

Hack everything without fear

166 points by RX14 9y ago

fouc 9y ago
It's not a "how to" like I thought it was going to be. It's a "do it" with some tips. Where "do it" is go ahead and hack & submit a patch on that open source project you rely on instead of working around it, get past that fear.
- adamson 9y ago
  I've never really understood why this is hard for people, especially in the era of Github where anyone and everyone can open an issue or pull request and generally be taken seriously.
  - bobjob 9y ago
    For some it is the fear of delivering ugly/subpar code.
    - QasimK 9y ago
      It is possible for your contribution to be so bad that it is actually harmful that you tried in the first place - but that's a pretty extreme situation. For the benefit of both the maintainers and the contributors, projects should really have advanced, comprehensive, automated code linting/style-checking/safety/etc. It should be possible to run it locally, and it should also integrate with GitHub's Pull Requests with automated comments (e.g. Travis CI). This should instil confidence in the contributor, they know they have at least passed the basic checks.
    - exikyut 9y ago
      I wonder if there's a fear under that of being mocked because someone else has different aesthetic preferences. Well, in this day and age, that kind of thing gets called out pretty quickly.
  - kovek 9y ago
    I've found it easy with python recently. - Go on github, find the repo - Fork the repo - git clone https://github.com/me/forked_repo https://github.com/me/forked_repo - cd into the repo, and 'git checkout -b me_myfix' - write your change - cd .. - 'pip uninstall forked_repo' so that you can work with your fork's clone instead - Sometimes, if the repo has a setup.py, some symbolic linking needs to be setup so we can easily do 'import forked_repo' - use 'import forked_repo' - later, you can do 'git push origin me_myfix' and submit a pull request from Github. I think there is a better way but I did not think about this problem much. It would be nice if someone could outline how to go about this properly. And there's almost no chance I could do this with another language since I am not as comfortable with the building/packaging with other languages.
    - pjscott 9y ago
      That should mostly apply to other languages. Only the pip/import parts differ, and those generally have straightforward counterparts since most package management systems these days are pretty similar.
    - UncleEntity 9y ago
      Sometimes you don't even need to do a pull request if you have your fork on the same platform. A while back I needed py3k support in pybindgen so hacked it in and it magically got merged into the main branch. Surprisingly, as is -- I guess I can hack on the python good enough ;)
xstartup 9y ago
Once I was interested in obscure code base because my motivation was to discover smth which a few people would know about. But these days, I see github repo with large number of contributors, who are smarter than me (often), it's an instant motivation killer. I rarely checkout other's code unless it's related to the problem I am solving.
- justboxing 9y ago
  What's 'smth' ?
  - Waterluvian 9y ago
    "something" I think.
- deckard1 9y ago
  If you work at a company with a large code base, you quickly come to realize that few people know how everything works. Most people only know a single part of the code that they are working on intimately. It's this intimately part that scares some people. Because each person working on the code intimately creates the picture that each person knows everything about the code. Which just isn't true. Start small and make sure you talk to the maintainers and make sure they are comfortable with you and what you want to work on. Introduce tiny patches to begin with. You'll disarm any gatekeepers this way, and get people on your side with you. The larger the project, the more politics involved generally.
- John_KZ 9y ago
  I actually suffer from an extra problem. I no longer trust any program you can download off the internet, except for trusted repositories (ie most of canonical's ubuntu repos, debian etc). That has been a massive drag for me, because I can't just download super convinient programs on my work computer. It pretty much stalled my interest in (amateur/hobby) programming alongside with stopping the use of pirated software, except in VMs, which are slow and inconvenient enough to not bother running them very often.
  - 9y ago
mythas 9y ago
Like most hard things in life the most honest advice anyone can give you is stop worrying about getting stuck, embrace confusion and learn to love being lost. If you can learn to not lose confidence when you’re in the wilderness then you have learned how to learn. Unfortunately this is challenging to do. It’s like telling someone the way to do a pull up is to do a pull-up. For self motivated people this is all the coaching they need. For most however, they need someone to hold their hand through all the steps.
- Waterluvian 9y ago
  I spent hours last night figuring out why some base64 PNGs wouldn't render. That used to be a classic example of something that would frustrate me to my wits end. But this time it was so much fun to understand the problem intimately. It helps that I have the flexibility to dig in instead of feeling the timeline pinch.
- alfonsodev 9y ago
  Actually, I was stuck for years, not being able to do a single pull-up, until I found a youtube video that explained how to progress in pull ups[1] The way was counterintuitive to me, so it would have never occurred to me. The method consists in actually jumping, skipping the hardest part, then when being on top with the head above the bar, you let your body fall as slowly as you can. It turns out this works because in the eccentric phase your arm muscles are more powerful, but you are still able to progress overall. The advice I would give is, as you said, embrace confusion but pay attention to where is your next mentor, the one that will show you that little trick or that little piece of understanding that will get you progressing. [1](spanish)https://www.youtube.com/watch?v=tQxbnI3QFBE https://www.youtube.com/watch?v=tQxbnI3QFBE
  - 52-6F-62 9y ago
    Another way is to work negatively. So in a sense you do a pull up by doing a reverse pull up— that is you start at the top of the pull us and lower yourself as slowly as possible (like in you’re method). Just rather than pulling yourself up you just jump yourself or step up to the top. After so many sessions of that you’ll be doing them without much difficulty. I’ve found in learning the process can be similar. If I don’t understand something I can only read so much and study so much. I have to get my hands into it. I will pull down a codebase, run it, change it, break it, fix it, try and emulate it from first principles and contrast that with my reading and repeat. The best way I’ve found so far is to couple that with bottom up learning— working and reworking the fundamentals as I capitulate and bounce off the walls of reverse engineering and experimenting. I can’t confirm the benefits of that for anybody else but it works for me and keeps me interested
trevyn 9y ago
“Do everything without fear” is also good advice. :-)
randcraw 9y ago
This used to called a “can do” attitude. Back then I think it meant you were willing to roll up your sleeves and do the hard physical work needed to put things right. Now that the world is more technical than mechanical, “can do” requires delving into circuits and SLOC, hacking far less visible and more complex entities. It's only when those circuits and apps are open that “can do” has a hope of staying alive. In the closed worlds of today's mobile infractructure (i.e. iOS and Droid “walled gardens”), remaining “can do” is getting harder. If I could trade mine in for a truly open smart phone, I'd do it in a heartbeat.
- seba_dos1 9y ago
  I'm still using Nokia N900, which is pretty close. I've used Openmoko Neo Freerunner pretty long, but unfortunately its performance was hard to stand anymore. For development, I also have Samsung Galaxy S3, which was the last one to have its baseband separated from the CPU. Replicant works there, so it might be a good choice in this regard as well. Looking forward for Librem 5, Neo900 or Pyra Phone now - whichever happens first. You need to make some sacrifices (hopefully less and less as the time passes), but the choice is there.
draw_down 9y ago
I suppose it’s good advice since you do need to be able to do this. But goodness is it not fun. If I can just change an argument and save myself a 45-minute dive through some godawful Ruby class tree (X inherits from Y inherits from Z... 7 layers deep until you find the method that actually does the thing), I will. I dunno, I’m just not one of those people who relishes in what I could possibly do. I’m more tired of broken/crappy stuff than I am excited at the prospect of fixing it all.
2glasscups 9y ago
"You don't know what you don't know until you go looking." Every good problem solver starts with the drive to want to solve the problem. People's motivations can vary from person to person, but these motivations are what drive them forward to want to solve the problem. Success is always a natural outcome of any problem solving technique used because even if the problem is not solved per the requirements needed, the experience of failing is still in many ways a success. The lessons learned from struggling and failing are committed to memory and can be used on another future problem. "Instead of looking for the answer, try to find a solution."
exikyut 9y ago
I think this article is fundamentally very bad, for one specific reason. --- Me: "Hi! I just found a bug in your program. If you do A, B and C, X doesn't work properly." Maintainer: "Our test case covers A and B and works perfectly." Me: "Yes, C is an edge-case your testcase didn't include, and which is what breaks everything horribly. You know more about modifying your testcase than I do, but I guarantee you that when you make the change, this will fail consistently." Maintainer: "You must provide us a new testcase." Me: "I don't know how to do that." Maintainer: "Our existing test cases work fine." Me: [ Gives up before frustration turns to anger ] This happened. https://github.com/rg3/youtube-dl/issues/7872 https://github.com/rg3/youtube-dl/issues/7872 -- Me (on a sadly now-defunct forum): "I think it would be awesome if we ported my favorite application to this new OS" Owner of application, unexpectedly: [ Long rant about the difficulty of porting things and that my ideas are going to affect him personally ] Me: [ Freaks out ] Forum maintainers: [ Words of comfort ] Sadly there are no copies of the post in the Web Archive (I just downloaded the entire forum to check), but I remember the conversation well. -- New contributor: "Here's a patch to this program. It fixes this and that problem." Long-term maintainer: "We don't do things that way." New contributor: "It'll improve performance and simplify the code." Long-term maintainer: [ Blah blah blahblahblahblahblahblahblahblah(...) ] New contributor: "...?!" This is what came to mind when I thought about systemd. --- The thing the article is completely missing is the political element. It exists, it's real, I wasn't warned I'd get bitten, and I have cognitive issues and don't know how to resolve confrontation in some situations. I generally avoid open source communities nowadays. My experiences discussing closed-source software have consistently been less toxic!
- dasil003 9y ago
  Patch politics aside, you can at least understand the problem and come up with workarounds based on your understanding.
- JdeBP 9y ago
  What is actually in that GitHub issue does not match your story. For example, what we can see there is you providing an example with the concrete information all replaced with "(removed)", the other person asking for said concrete information, and you replying that you don't know it, even though you clearly did and removed it from your test case.

166 points by RX14 9y ago

fouc 9y ago

It's not a "how to" like I thought it was going to be. It's a "do it" with some tips. Where "do it" is go ahead and hack & submit a patch on that open source project you rely on instead of working around it, get past that fear.

adamson 9y ago
I've never really understood why this is hard for people, especially in the era of Github where anyone and everyone can open an issue or pull request and generally be taken seriously.
- bobjob 9y ago
  For some it is the fear of delivering ugly/subpar code.
  - QasimK 9y ago
    It is possible for your contribution to be so bad that it is actually harmful that you tried in the first place - but that's a pretty extreme situation. For the benefit of both the maintainers and the contributors, projects should really have advanced, comprehensive, automated code linting/style-checking/safety/etc. It should be possible to run it locally, and it should also integrate with GitHub's Pull Requests with automated comments (e.g. Travis CI). This should instil confidence in the contributor, they know they have at least passed the basic checks.
  - exikyut 9y ago
    I wonder if there's a fear under that of being mocked because someone else has different aesthetic preferences. Well, in this day and age, that kind of thing gets called out pretty quickly.
- kovek 9y ago
  I've found it easy with python recently. - Go on github, find the repo - Fork the repo - git clone https://github.com/me/forked_repo https://github.com/me/forked_repo - cd into the repo, and 'git checkout -b me_myfix' - write your change - cd .. - 'pip uninstall forked_repo' so that you can work with your fork's clone instead - Sometimes, if the repo has a setup.py, some symbolic linking needs to be setup so we can easily do 'import forked_repo' - use 'import forked_repo' - later, you can do 'git push origin me_myfix' and submit a pull request from Github. I think there is a better way but I did not think about this problem much. It would be nice if someone could outline how to go about this properly. And there's almost no chance I could do this with another language since I am not as comfortable with the building/packaging with other languages.
  - pjscott 9y ago
    That should mostly apply to other languages. Only the pip/import parts differ, and those generally have straightforward counterparts since most package management systems these days are pretty similar.
  - UncleEntity 9y ago
    Sometimes you don't even need to do a pull request if you have your fork on the same platform. A while back I needed py3k support in pybindgen so hacked it in and it magically got merged into the main branch. Surprisingly, as is -- I guess I can hack on the python good enough ;)

xstartup 9y ago

Once I was interested in obscure code base because my motivation was to discover smth which a few people would know about. But these days, I see github repo with large number of contributors, who are smarter than me (often), it's an instant motivation killer. I rarely checkout other's code unless it's related to the problem I am solving.

justboxing 9y ago
What's 'smth' ?
- Waterluvian 9y ago
  "something" I think.
deckard1 9y ago
If you work at a company with a large code base, you quickly come to realize that few people know how everything works. Most people only know a single part of the code that they are working on intimately. It's this intimately part that scares some people. Because each person working on the code intimately creates the picture that each person knows everything about the code. Which just isn't true. Start small and make sure you talk to the maintainers and make sure they are comfortable with you and what you want to work on. Introduce tiny patches to begin with. You'll disarm any gatekeepers this way, and get people on your side with you. The larger the project, the more politics involved generally.
John_KZ 9y ago
I actually suffer from an extra problem. I no longer trust any program you can download off the internet, except for trusted repositories (ie most of canonical's ubuntu repos, debian etc). That has been a massive drag for me, because I can't just download super convinient programs on my work computer. It pretty much stalled my interest in (amateur/hobby) programming alongside with stopping the use of pirated software, except in VMs, which are slow and inconvenient enough to not bother running them very often.
- 9y ago

mythas 9y ago

Like most hard things in life the most honest advice anyone can give you is stop worrying about getting stuck, embrace confusion and learn to love being lost. If you can learn to not lose confidence when you’re in the wilderness then you have learned how to learn. Unfortunately this is challenging to do. It’s like telling someone the way to do a pull up is to do a pull-up. For self motivated people this is all the coaching they need. For most however, they need someone to hold their hand through all the steps.

Waterluvian 9y ago
I spent hours last night figuring out why some base64 PNGs wouldn't render. That used to be a classic example of something that would frustrate me to my wits end. But this time it was so much fun to understand the problem intimately. It helps that I have the flexibility to dig in instead of feeling the timeline pinch.
alfonsodev 9y ago
Actually, I was stuck for years, not being able to do a single pull-up, until I found a youtube video that explained how to progress in pull ups[1] The way was counterintuitive to me, so it would have never occurred to me. The method consists in actually jumping, skipping the hardest part, then when being on top with the head above the bar, you let your body fall as slowly as you can. It turns out this works because in the eccentric phase your arm muscles are more powerful, but you are still able to progress overall. The advice I would give is, as you said, embrace confusion but pay attention to where is your next mentor, the one that will show you that little trick or that little piece of understanding that will get you progressing. [1](spanish)https://www.youtube.com/watch?v=tQxbnI3QFBE https://www.youtube.com/watch?v=tQxbnI3QFBE
- 52-6F-62 9y ago
  Another way is to work negatively. So in a sense you do a pull up by doing a reverse pull up— that is you start at the top of the pull us and lower yourself as slowly as possible (like in you’re method). Just rather than pulling yourself up you just jump yourself or step up to the top. After so many sessions of that you’ll be doing them without much difficulty. I’ve found in learning the process can be similar. If I don’t understand something I can only read so much and study so much. I have to get my hands into it. I will pull down a codebase, run it, change it, break it, fix it, try and emulate it from first principles and contrast that with my reading and repeat. The best way I’ve found so far is to couple that with bottom up learning— working and reworking the fundamentals as I capitulate and bounce off the walls of reverse engineering and experimenting. I can’t confirm the benefits of that for anybody else but it works for me and keeps me interested

trevyn 9y ago

“Do everything without fear” is also good advice. :-)

randcraw 9y ago

This used to called a “can do” attitude. Back then I think it meant you were willing to roll up your sleeves and do the hard physical work needed to put things right. Now that the world is more technical than mechanical, “can do” requires delving into circuits and SLOC, hacking far less visible and more complex entities. It's only when those circuits and apps are open that “can do” has a hope of staying alive. In the closed worlds of today's mobile infractructure (i.e. iOS and Droid “walled gardens”), remaining “can do” is getting harder. If I could trade mine in for a truly open smart phone, I'd do it in a heartbeat.

seba_dos1 9y ago
I'm still using Nokia N900, which is pretty close. I've used Openmoko Neo Freerunner pretty long, but unfortunately its performance was hard to stand anymore. For development, I also have Samsung Galaxy S3, which was the last one to have its baseband separated from the CPU. Replicant works there, so it might be a good choice in this regard as well. Looking forward for Librem 5, Neo900 or Pyra Phone now - whichever happens first. You need to make some sacrifices (hopefully less and less as the time passes), but the choice is there.

draw_down 9y ago

I suppose it’s good advice since you do need to be able to do this. But goodness is it not fun. If I can just change an argument and save myself a 45-minute dive through some godawful Ruby class tree (X inherits from Y inherits from Z... 7 layers deep until you find the method that actually does the thing), I will. I dunno, I’m just not one of those people who relishes in what I could possibly do. I’m more tired of broken/crappy stuff than I am excited at the prospect of fixing it all.

2glasscups 9y ago

"You don't know what you don't know until you go looking." Every good problem solver starts with the drive to want to solve the problem. People's motivations can vary from person to person, but these motivations are what drive them forward to want to solve the problem. Success is always a natural outcome of any problem solving technique used because even if the problem is not solved per the requirements needed, the experience of failing is still in many ways a success. The lessons learned from struggling and failing are committed to memory and can be used on another future problem. "Instead of looking for the answer, try to find a solution."

exikyut 9y ago

I think this article is fundamentally very bad, for one specific reason. --- Me: "Hi! I just found a bug in your program. If you do A, B and C, X doesn't work properly." Maintainer: "Our test case covers A and B and works perfectly." Me: "Yes, C is an edge-case your testcase didn't include, and which is what breaks everything horribly. You know more about modifying your testcase than I do, but I guarantee you that when you make the change, this will fail consistently." Maintainer: "You must provide us a new testcase." Me: "I don't know how to do that." Maintainer: "Our existing test cases work fine." Me: [ Gives up before frustration turns to anger ] This happened. https://github.com/rg3/youtube-dl/issues/7872 https://github.com/rg3/youtube-dl/issues/7872 -- Me (on a sadly now-defunct forum): "I think it would be awesome if we ported my favorite application to this new OS" Owner of application, unexpectedly: [ Long rant about the difficulty of porting things and that my ideas are going to affect him personally ] Me: [ Freaks out ] Forum maintainers: [ Words of comfort ] Sadly there are no copies of the post in the Web Archive (I just downloaded the entire forum to check), but I remember the conversation well. -- New contributor: "Here's a patch to this program. It fixes this and that problem." Long-term maintainer: "We don't do things that way." New contributor: "It'll improve performance and simplify the code." Long-term maintainer: [ Blah blah blahblahblahblahblahblahblahblah(...) ] New contributor: "...?!" This is what came to mind when I thought about systemd. --- The thing the article is completely missing is the political element. It exists, it's real, I wasn't warned I'd get bitten, and I have cognitive issues and don't know how to resolve confrontation in some situations. I generally avoid open source communities nowadays. My experiences discussing closed-source software have consistently been less toxic!

dasil003 9y ago
Patch politics aside, you can at least understand the problem and come up with workarounds based on your understanding.
JdeBP 9y ago
What is actually in that GitHub issue does not match your story. For example, what we can see there is you providing an example with the concrete information all replaced with "(removed)", the other person asking for said concrete information, and you replying that you don't know it, even though you clearly did and removed it from your test case.