3 ms·

IME, this only works if you can get regular help from them. A one-off won't help much at all.

keepamovin 3y ago
Yeah you need to cultivate those relationships. But with a willing partner that first session will take you from 0 to 1 :)
- mst 3y ago
  A lot of the time it takes you from 0 to 0.1, but (a) every little helps (b) if you take them out for lunch or a post-work beer or whatever it can build a relationship where you can ask follow up questions via email. Ideal is if they have a life such that something morally equivalent to "how about we meet up and I'll pay for the food/beer" is a viable thing to suggest later. Oh, and always remember - the way to a geek's schedule is often through their wife. If you get a chance to meet their partner, TAKE IT and be on your best behaviour, if $partner likes you then you have massively increased chances of making useful things happen later.
  - keepamovin 3y ago
    Yeah, that's a good point. But I think more often it's closer to 1 because (I guess this depends on our definition of 0 and 1 haha! :)) a) you get the benefit of their conceptual models for thinking about the codebase, which is hard won and highly useful, and b) you grok any practical pitfalls or things to remember when running, building, testing, that may be simple enough, but in the space of all possibilities are hard to come by without knowing them. So basically you get to go from: 0 - can do nothing at all; to 1 - being able to feel confident diving in and looking around, framed with the downloaded conceptual models, knowing how to hit the ground trotting, if not running. To me, 0.1 is more like you slugged it out for a couple hours poking around by yourself, and now you know a handful of confusing things with low confidence. Chatting to one who has been there, done that lets you have more confidence, and know more actionable stuff, which is highly useful. I suppose it depends on your conversation, listening and comprehension skills tho! Hahaha! :) But seriously not everybody learns well in that situation. I just happen to. I'd much rather talk it over with someone and absorb, than watch a video or read a tutorial. Finally -- haha! :) -- I guess there are some geeks to whose schedule the way is through their husband or whatevs haha! :)
Joel_Mckay 3y ago
I've always found discussing why former employees left a project incredibly enlightening. They will usually explain the reality behind the PR given they are no longer involved in the politics. Most importantly they will often tell you your best case future with a firm. Normally, employment agreements specifically restrict contact with former staff, or discussions of sensitive matters like compensation packages. C++ is like any other language, in that it will often take 3 times longer to understand something than re-implement the same. If you are lucky, than everything is a minimal API lib, and you get repetitive examples of the use cases... but the cooperative OSS breadcrumb model almost never happens in commercial shops... Legacy code bases can be hell to work with, as you end up with the responsibility for 14 years of IT kludges. Also, the opinions from entrenched lamers on what productivity means will be painful at first. Usually, with C++ it can become its own project specific language variant (STL or Boost may help wrangle the chaos). You have my sympathy, but no checklist can help with naive design inertia. Have a wonderful day. =)
- keepamovin 3y ago
  Uh, yeah, that's a great idea, too! That's the big question. What happened to the previous team? Can give you org insights as well as code ones. Info on company strategy, priorities, work cadence. Actually a pretty good open ended conversation opener! Hahaha! :)
- saagarjha 3y ago
  Note that depending on your jurisdiction discussion of compensation may be a right protected by law.
  - Joel_Mckay 3y ago
    Contract law has weird consequences in different places. Indeed, if the legal encumbrance is not legal, than its often unenforceable. Talking with your own lawyers before doing something silly is a good habit. ;-)
mellutussa 3y ago
> A one-off won't help much at all. Monumentally disagree. One-off session with a guy who knows the codebase inside out can save you days of research work. Plus telling you all about the problematic/historical areas.
- Night_Thastus 3y ago
  I'm just stating my experience. A single day, if they still have access to the codebase might be able to clear up some top-level concepts. But the devil is in all the tiny details. What is this tiny correction factor that was added 20 years ago? Why was this value cut off to X decimals? Why didn't they just do Y here? Why do we override this default behavior? It's tens of thousands of tiny questions like that which you can't ask until you're there.
  - slingnow 3y ago
    I don't understand what you're saying. Clearly both types of meetings (one-off vs recurring) would be helpful. The one-off may save you days/weeks of research, but it seems like you're not satisfied with that unless you can answer every single minor question you might have across the entire codebase.
    - Night_Thastus 3y ago
      I'm saying that if you're maintaining a code base for years, a single day's explanations won't do much of anything. It's a drop in the bucket. It's not a bad thing, and it's certainly good to do, but it's not a solution to the problem.
      - mellutussa 3y ago
        If your granularity for a task is measured in years then you have a much different and harder problem. Effectively everything becomes a "drop in the bucket".
        3y ago

Yeah you need to cultivate those relationships. But with a willing partner that first session will take you from 0 to 1 :)

mst 3y ago
A lot of the time it takes you from 0 to 0.1, but (a) every little helps (b) if you take them out for lunch or a post-work beer or whatever it can build a relationship where you can ask follow up questions via email. Ideal is if they have a life such that something morally equivalent to "how about we meet up and I'll pay for the food/beer" is a viable thing to suggest later. Oh, and always remember - the way to a geek's schedule is often through their wife. If you get a chance to meet their partner, TAKE IT and be on your best behaviour, if $partner likes you then you have massively increased chances of making useful things happen later.
- keepamovin 3y ago
  Yeah, that's a good point. But I think more often it's closer to 1 because (I guess this depends on our definition of 0 and 1 haha! :)) a) you get the benefit of their conceptual models for thinking about the codebase, which is hard won and highly useful, and b) you grok any practical pitfalls or things to remember when running, building, testing, that may be simple enough, but in the space of all possibilities are hard to come by without knowing them. So basically you get to go from: 0 - can do nothing at all; to 1 - being able to feel confident diving in and looking around, framed with the downloaded conceptual models, knowing how to hit the ground trotting, if not running. To me, 0.1 is more like you slugged it out for a couple hours poking around by yourself, and now you know a handful of confusing things with low confidence. Chatting to one who has been there, done that lets you have more confidence, and know more actionable stuff, which is highly useful. I suppose it depends on your conversation, listening and comprehension skills tho! Hahaha! :) But seriously not everybody learns well in that situation. I just happen to. I'd much rather talk it over with someone and absorb, than watch a video or read a tutorial. Finally -- haha! :) -- I guess there are some geeks to whose schedule the way is through their husband or whatevs haha! :)

Joel_Mckay 3y ago

I've always found discussing why former employees left a project incredibly enlightening. They will usually explain the reality behind the PR given they are no longer involved in the politics. Most importantly they will often tell you your best case future with a firm. Normally, employment agreements specifically restrict contact with former staff, or discussions of sensitive matters like compensation packages. C++ is like any other language, in that it will often take 3 times longer to understand something than re-implement the same. If you are lucky, than everything is a minimal API lib, and you get repetitive examples of the use cases... but the cooperative OSS breadcrumb model almost never happens in commercial shops... Legacy code bases can be hell to work with, as you end up with the responsibility for 14 years of IT kludges. Also, the opinions from entrenched lamers on what productivity means will be painful at first. Usually, with C++ it can become its own project specific language variant (STL or Boost may help wrangle the chaos). You have my sympathy, but no checklist can help with naive design inertia. Have a wonderful day. =)

keepamovin 3y ago
Uh, yeah, that's a great idea, too! That's the big question. What happened to the previous team? Can give you org insights as well as code ones. Info on company strategy, priorities, work cadence. Actually a pretty good open ended conversation opener! Hahaha! :)
saagarjha 3y ago
Note that depending on your jurisdiction discussion of compensation may be a right protected by law.
- Joel_Mckay 3y ago
  Contract law has weird consequences in different places. Indeed, if the legal encumbrance is not legal, than its often unenforceable. Talking with your own lawyers before doing something silly is a good habit. ;-)

mellutussa 3y ago

> A one-off won't help much at all. Monumentally disagree. One-off session with a guy who knows the codebase inside out can save you days of research work. Plus telling you all about the problematic/historical areas.

Night_Thastus 3y ago
I'm just stating my experience. A single day, if they still have access to the codebase might be able to clear up some top-level concepts. But the devil is in all the tiny details. What is this tiny correction factor that was added 20 years ago? Why was this value cut off to X decimals? Why didn't they just do Y here? Why do we override this default behavior? It's tens of thousands of tiny questions like that which you can't ask until you're there.
- slingnow 3y ago
  I don't understand what you're saying. Clearly both types of meetings (one-off vs recurring) would be helpful. The one-off may save you days/weeks of research, but it seems like you're not satisfied with that unless you can answer every single minor question you might have across the entire codebase.
  - Night_Thastus 3y ago
    I'm saying that if you're maintaining a code base for years, a single day's explanations won't do much of anything. It's a drop in the bucket. It's not a bad thing, and it's certainly good to do, but it's not a solution to the problem.
    - mellutussa 3y ago
      If your granularity for a task is measured in years then you have a much different and harder problem. Effectively everything becomes a "drop in the bucket".
      - 3y ago