6 ms·

Realizing that external dependencies are regular codebases just like the one you're working on. That you can open them up in VSCode, look around and figure out

Realizing that external dependencies are regular codebases just like the one you're working on. That you can open them up in VSCode, look around and figure out any bugs or issues you're having and even open pull requests to improve them. At that point, you lose the feeling that there are magic things out there that you will never understand and that for the most part everything is just regular old code that regular people wrote.

wing-_-nuts 3y ago
Adding to this, the decompiler built in to many ides really up'd my game understanding underlying libs. How they work, what methods to call, etc. Very helpful! As much as people trash java this is a really nice feature. I'm sure other languages have decompilers as well, but I've never seen anything close for c# for example.
- whiskey14 3y ago
  In python pdb ‘breakpoint()’ is great
- DeathArrow 3y ago
  >I've never seen anything close for c# for example If you highlight a method you call from external code and hit CTRL + F12, Visual Studio will automatically decompile it for you.
- rjbwork 3y ago
  >I'm sure other languages have decompilers as well, but I've never seen anything close for c# for example. Dotpeek is integrated into Rider and is a world class decompiler. It also integrates into Visual Studio either standalone, or with ReSharper. You can also integrate external source symbol servers into your IDE of choice as well that will let you debug into libraries seamlessly.
- Tainnor 3y ago
  In the case of Java at least, what helps is that the IDE can decompile the code or, which is often even more helpful, download the source code and allow you to step through it while debugging, at least if a source JAR was published (which is pretty often the case). In the case of non-compiled languages, of course you don't even need this step since all your libs exist in source form already, so it was pretty simple for me to step through Ruby library code with a simple debugger and no fancy IDE. I have a habit of sometimes debugging even horribly abstract framework (e.g. Spring) code when I don't understand what it's doing. That's maybe not the most efficient method, but it does usually make me understand why thing X is not working the way I expected it to work.
whstl 3y ago
This is indeed a superpower. I don't really remember when I felt that external dependencies were magic, but thinking about this, it explains a lot of the behavior I see on some developers who are very negative about the more challenging parts of the job. Some of them don't really believe the research stuff we do at work are even possible. They're constantly surprised when other devs finish those tasks. Some don't believe that other devs can code in C++ or Rust, or write parsers, database modules, implement IQueryable in C#, or develop novel algorithms for novel applications. To them, if a package exists it must just work, and that package comes from another breed of developer that can't coexist with them. I see a similar thinking with AI: now with ChatGPT and GPT-4, there's a hubbub about there being "no reason for our AI team to exist anymore". I'm not a big fan of working with those developers.
- JohnFen 3y ago
  > I'm not a big fan of working with those developers I agree. And it ties into something I often see that puts me on edge: programmers not taking responsibility for the code they put into their projects. What I mean is that when you incorporate any code, from any source (library, framework, copypaste, etc), then you are responsible for that code and its proper behavior as much as for the code you actually wrote. So you're well-advised to understand it. That's one of the reasons why I won't include code that I don't have the source code to. I need to understand it and be able to fix it.
  - whstl 3y ago
    Good point. The "out of sight, out of mind" approach doesn't really work for code you're actually responsible for.
- gamacodre 3y ago
  I've worked with some of those folks too. It seems to me like they haven't really learned programming the way I understand it; instead, they've learned various incantations that can be strung together, and are just at a loss when they don't work as expected/documented.
brvsft 3y ago
Funny thing was I never even thought to do this until I was working on a very strange bug, and a senior engineer at my company suggested I look at the source code for one of our dependencies. Sometimes really obvious and basic advice can be a big step for people.
- macNchz 3y ago
  Yeah I think it's helpful to recognize that this isn't always obvious to people, even folks who seem like they'd instinctively do so–I had a similar experience a year or two into being a professional programmer, despite being someone whose first experience with dependencies years beforehand was downloading Perl files and directly editing them.
- valenceelectron 3y ago
  Had a similar experience during my Bachelors thesis. I was adding new functionality to an existing code inspection framework and was also supposed to add a graphical interface with GTK (this was 2014). At some point I identified a performance bottleneck within a GTK component. My advisor suggested fixing it and I just couldn't understand how I lowly student am supposed to tackle anything in this big behemoth. In the end, I didn't do it but it made me think and jump into various big open source projects in the following years. And you get used to navigating these suprisingly fast.
activitypea 3y ago
Whenever I have this situation, it's always with a library too big for my smooth little brain to comprehend.
- d4mi3n 3y ago
  The trick is to dig deeper into those big library's dependencies as well. It's turtles all the way down. The other thing I find is that big libraries are either mostly dependency bloat (as implied above) or dealing with a hard domain problem. If it's the latter, what you're really struggling with is not the library, but the domain it's trying to represent.
  - hutzlibu 3y ago
    "If it's the latter, what you're really struggling with is not the library, but the domain it's trying to represent." But this doesn't change anything of the programmers problem. If I stumble on a bug in a physics libary I am using for a game, I cannot just jump right into there and go fixing things. I mean I can start doing it, but at the cost of not getting anything else done for quite some time. There are lots of hard domains in programming. Cryptography is hard. Networking is hard. Fast rendering is hard. Efficient DBs are hard. OS are hard. Drivers are hard. You can maybe fix a trivial error in such libaries, but everything else is usually a (big) project on its own.
    - d4mi3n 3y ago
      Absolutely correct, but I think it’s still valuable to be able to recognize if you’re struggling against the code or the domain. Additionally, once you recognize that you can also recognize if you’re dealing with incidental complexity (e.g. poorly thought out/designed code) and inherent complexity (e.g. physics calculations). The former can be fixed, the latter cannot. Knowing the difference saves much pain.
cj 3y ago
Relatedly, understand the frameworks that you build upon. For React devs, this means learning how React actually works under the hood.
steve_adams_86 3y ago
My favourite language for this is Go. The standard library is totally exposed and easy to jump into, right there for you to learn from and to make sense not only of the library but how to actually write Go in the first place.
- kubanczyk 3y ago
  CGO_ENABLED=0 for new projects though :)
LudwigNagasena 3y ago
Not all external dependencies are noncompiled. Also, library code is often different from your regular codebase especially in a language like C.
geitir 3y ago
Just calling out that if it weren’t for open source this would be much harder
bmitc 3y ago
Imagine any other profession needing to inspect, rebuild, and fix the tools that they are given to do their job.
- rootw0rm 3y ago
  that's actually, um...common? i just had to repair an electric jackhammer last week. i worked in a machine shop for a large well drilling company not long ago, and not only did we create/repair tools for the company, but obviously had to keep our mills and lathes and cranes, etc. in good working condition.
  - bmitc 3y ago
    It's not common in the same sense. First of all, tools are very different from software products. And there is never the same level of analogy that one has to do in software. Imagine buying a hammer, that hammer not working, the hammer's design being so complicated that it's impossible to understand or mend, and then having to design and build your own hammer, and then putting up with that situation over and over again and accepting that as the status quo. That would be the correct analogy.
    - nik_0_0 3y ago
      I'll agree wholeheartedly that the analogy needs some work. Tools are different - we have our literal physical tools that we don't generally dive into (keyboards, mice), we have tools that are maybe more battle tested and rarely examined (cat, grep, find). We have do have tools like the hammer - there is one design, everyone more or less agrees on it. There is still high quality and low quality, but it has one job. We have tools like a bulldozer - complex, numerous parts, requires constant maintenance, closed source. As the parent said - it is not uncommon to have to maintain old equipment, as well as design new tools as new requirements pop up. Sure, our rust is a little bit different - time wears on software in a different way. Use wears on software differently. (Changing product requirements leading to a new tool is probably common.) The maintenance may be trickier - but I'm sure changing components on a tool when a certain component is no longer available is not easy, thats where shim layer comes from!
vidyesh 3y ago
> That you can open them up in VSCode, look around and figure out any bugs or issues you're having and even open pull requests to improve them. I think the real skill then is to learn to navigate big codebases in few days time than taking a few weeks and then feel dejected by the time spent and still unsure. I often feel ambitious for such endeavors but navigating big codebases take time, any tips?
- edg5000 3y ago
  It helps if you can get your IDE's indexer configured, so that you find refererences to functions and variables reliably. More importantly is to use an IDE with a good fast global search function and get comfortable with it. At least for me, 99% of navigating a large codebase is global search.
  - bonniesimon 3y ago
    Is there a way to get vscode to this level.
    - edg5000 3y ago
      For C++, I use clangd (works fine for GCC projects). The only config it needs is the path to compile_commands.json, which can be automatically generated by CMake and some other build systems. For TypeScript no config is needed. For Java there is the redhad Java plugin in VS which provides good indexing.
    - vidyesh 3y ago
      Not using VSCode currently but I think pretty much yes. You can goto or peek definition in VSCode. And the find tool has the option to find all occurrences throughout your project.
  - missingdays 3y ago
    Or use an ide that doesn't need indexed configured and just works
euske 3y ago
"I was an ordinary person who studied hard. There are no miracle people. It happens they get interested in this thing and they learn all this stuff, but they’re just people." - Richard Feynmann
yayitswei 3y ago
This. My favorite language for this is Clojure. There's usually not much library code to sift through because it's so terse.

wing-_-nuts 3y ago

Adding to this, the decompiler built in to many ides really up'd my game understanding underlying libs. How they work, what methods to call, etc. Very helpful! As much as people trash java this is a really nice feature. I'm sure other languages have decompilers as well, but I've never seen anything close for c# for example.

whiskey14 3y ago
In python pdb ‘breakpoint()’ is great
DeathArrow 3y ago
>I've never seen anything close for c# for example If you highlight a method you call from external code and hit CTRL + F12, Visual Studio will automatically decompile it for you.
rjbwork 3y ago
>I'm sure other languages have decompilers as well, but I've never seen anything close for c# for example. Dotpeek is integrated into Rider and is a world class decompiler. It also integrates into Visual Studio either standalone, or with ReSharper. You can also integrate external source symbol servers into your IDE of choice as well that will let you debug into libraries seamlessly.
Tainnor 3y ago
In the case of Java at least, what helps is that the IDE can decompile the code or, which is often even more helpful, download the source code and allow you to step through it while debugging, at least if a source JAR was published (which is pretty often the case). In the case of non-compiled languages, of course you don't even need this step since all your libs exist in source form already, so it was pretty simple for me to step through Ruby library code with a simple debugger and no fancy IDE. I have a habit of sometimes debugging even horribly abstract framework (e.g. Spring) code when I don't understand what it's doing. That's maybe not the most efficient method, but it does usually make me understand why thing X is not working the way I expected it to work.

whstl 3y ago

This is indeed a superpower. I don't really remember when I felt that external dependencies were magic, but thinking about this, it explains a lot of the behavior I see on some developers who are very negative about the more challenging parts of the job. Some of them don't really believe the research stuff we do at work are even possible. They're constantly surprised when other devs finish those tasks. Some don't believe that other devs can code in C++ or Rust, or write parsers, database modules, implement IQueryable in C#, or develop novel algorithms for novel applications. To them, if a package exists it must just work, and that package comes from another breed of developer that can't coexist with them. I see a similar thinking with AI: now with ChatGPT and GPT-4, there's a hubbub about there being "no reason for our AI team to exist anymore". I'm not a big fan of working with those developers.

JohnFen 3y ago
> I'm not a big fan of working with those developers I agree. And it ties into something I often see that puts me on edge: programmers not taking responsibility for the code they put into their projects. What I mean is that when you incorporate any code, from any source (library, framework, copypaste, etc), then you are responsible for that code and its proper behavior as much as for the code you actually wrote. So you're well-advised to understand it. That's one of the reasons why I won't include code that I don't have the source code to. I need to understand it and be able to fix it.
- whstl 3y ago
  Good point. The "out of sight, out of mind" approach doesn't really work for code you're actually responsible for.
gamacodre 3y ago
I've worked with some of those folks too. It seems to me like they haven't really learned programming the way I understand it; instead, they've learned various incantations that can be strung together, and are just at a loss when they don't work as expected/documented.

brvsft 3y ago

Funny thing was I never even thought to do this until I was working on a very strange bug, and a senior engineer at my company suggested I look at the source code for one of our dependencies. Sometimes really obvious and basic advice can be a big step for people.

macNchz 3y ago
Yeah I think it's helpful to recognize that this isn't always obvious to people, even folks who seem like they'd instinctively do so–I had a similar experience a year or two into being a professional programmer, despite being someone whose first experience with dependencies years beforehand was downloading Perl files and directly editing them.
valenceelectron 3y ago
Had a similar experience during my Bachelors thesis. I was adding new functionality to an existing code inspection framework and was also supposed to add a graphical interface with GTK (this was 2014). At some point I identified a performance bottleneck within a GTK component. My advisor suggested fixing it and I just couldn't understand how I lowly student am supposed to tackle anything in this big behemoth. In the end, I didn't do it but it made me think and jump into various big open source projects in the following years. And you get used to navigating these suprisingly fast.

activitypea 3y ago

Whenever I have this situation, it's always with a library too big for my smooth little brain to comprehend.

d4mi3n 3y ago
The trick is to dig deeper into those big library's dependencies as well. It's turtles all the way down. The other thing I find is that big libraries are either mostly dependency bloat (as implied above) or dealing with a hard domain problem. If it's the latter, what you're really struggling with is not the library, but the domain it's trying to represent.
- hutzlibu 3y ago
  "If it's the latter, what you're really struggling with is not the library, but the domain it's trying to represent." But this doesn't change anything of the programmers problem. If I stumble on a bug in a physics libary I am using for a game, I cannot just jump right into there and go fixing things. I mean I can start doing it, but at the cost of not getting anything else done for quite some time. There are lots of hard domains in programming. Cryptography is hard. Networking is hard. Fast rendering is hard. Efficient DBs are hard. OS are hard. Drivers are hard. You can maybe fix a trivial error in such libaries, but everything else is usually a (big) project on its own.
  - d4mi3n 3y ago
    Absolutely correct, but I think it’s still valuable to be able to recognize if you’re struggling against the code or the domain. Additionally, once you recognize that you can also recognize if you’re dealing with incidental complexity (e.g. poorly thought out/designed code) and inherent complexity (e.g. physics calculations). The former can be fixed, the latter cannot. Knowing the difference saves much pain.

cj 3y ago

Relatedly, understand the frameworks that you build upon. For React devs, this means learning how React actually works under the hood.

steve_adams_86 3y ago

My favourite language for this is Go. The standard library is totally exposed and easy to jump into, right there for you to learn from and to make sense not only of the library but how to actually write Go in the first place.

kubanczyk 3y ago
CGO_ENABLED=0 for new projects though :)

LudwigNagasena 3y ago

Not all external dependencies are noncompiled. Also, library code is often different from your regular codebase especially in a language like C.

geitir 3y ago

Just calling out that if it weren’t for open source this would be much harder

bmitc 3y ago

Imagine any other profession needing to inspect, rebuild, and fix the tools that they are given to do their job.

rootw0rm 3y ago
that's actually, um...common? i just had to repair an electric jackhammer last week. i worked in a machine shop for a large well drilling company not long ago, and not only did we create/repair tools for the company, but obviously had to keep our mills and lathes and cranes, etc. in good working condition.
- bmitc 3y ago
  It's not common in the same sense. First of all, tools are very different from software products. And there is never the same level of analogy that one has to do in software. Imagine buying a hammer, that hammer not working, the hammer's design being so complicated that it's impossible to understand or mend, and then having to design and build your own hammer, and then putting up with that situation over and over again and accepting that as the status quo. That would be the correct analogy.
  - nik_0_0 3y ago
    I'll agree wholeheartedly that the analogy needs some work. Tools are different - we have our literal physical tools that we don't generally dive into (keyboards, mice), we have tools that are maybe more battle tested and rarely examined (cat, grep, find). We have do have tools like the hammer - there is one design, everyone more or less agrees on it. There is still high quality and low quality, but it has one job. We have tools like a bulldozer - complex, numerous parts, requires constant maintenance, closed source. As the parent said - it is not uncommon to have to maintain old equipment, as well as design new tools as new requirements pop up. Sure, our rust is a little bit different - time wears on software in a different way. Use wears on software differently. (Changing product requirements leading to a new tool is probably common.) The maintenance may be trickier - but I'm sure changing components on a tool when a certain component is no longer available is not easy, thats where shim layer comes from!

vidyesh 3y ago

> That you can open them up in VSCode, look around and figure out any bugs or issues you're having and even open pull requests to improve them. I think the real skill then is to learn to navigate big codebases in few days time than taking a few weeks and then feel dejected by the time spent and still unsure. I often feel ambitious for such endeavors but navigating big codebases take time, any tips?

edg5000 3y ago
It helps if you can get your IDE's indexer configured, so that you find refererences to functions and variables reliably. More importantly is to use an IDE with a good fast global search function and get comfortable with it. At least for me, 99% of navigating a large codebase is global search.
- bonniesimon 3y ago
  Is there a way to get vscode to this level.
  - edg5000 3y ago
    For C++, I use clangd (works fine for GCC projects). The only config it needs is the path to compile_commands.json, which can be automatically generated by CMake and some other build systems. For TypeScript no config is needed. For Java there is the redhad Java plugin in VS which provides good indexing.
  - vidyesh 3y ago
    Not using VSCode currently but I think pretty much yes. You can goto or peek definition in VSCode. And the find tool has the option to find all occurrences throughout your project.
- missingdays 3y ago
  Or use an ide that doesn't need indexed configured and just works

euske 3y ago

"I was an ordinary person who studied hard. There are no miracle people. It happens they get interested in this thing and they learn all this stuff, but they’re just people." - Richard Feynmann

yayitswei 3y ago

This. My favorite language for this is Clojure. There's usually not much library code to sift through because it's so terse.