12 ms·

The hard part is talking to hiring managers or potential clients about this without sounding like an idiot who doesn’t know how to put his or her shoes on the r

The hard part is talking to hiring managers or potential clients about this without sounding like an idiot who doesn’t know how to put his or her shoes on the right feet. What do other people do in those situations to communicate this?

dstick 6y ago
They lie?
- tudorgirba 6y ago
  :) That is intriguing. What do you mean?
  - WJW 6y ago
    You tell the managers that you will spend no time at all on figuring out the system because you are just that good. Of course, you will still need to spend some time on it. Hopefully nobody will look into it too closely, but even if they do, you can claim that that time was already part of the "fixing the problem" phase. Most managers will not look into the matter too closely, because if they find no wrongdoing then it was wasted time and if they do find it then they have to spend even more time to find a new freelancer. (And possibly take a reputational hit for hiring the wrong person in the first place)
chriszhang 6y ago
I have not faced this problem. I say that there will be a learning curve to understand the product before a new developer can start fixing bugs or adding enhancements. Managers have always understood it. For contractors too the learning curve is part of the deal. The contractors get paid by the hour when they are climbing the learning curve. Managers seem fine with it.
- tudorgirba 6y ago
  What is typically considered an acceptable learning cost / duration in your experience? I am not asking because I do not agree that there is a learning curve (we call it assessment), I am asking because I am curious what people expect.
  - pan69 6y ago
    > What is typically considered an acceptable learning cost / duration in your experience? How long does it take to do a crossword puzzle or play a game of chess? As with everything, it depends.
  - adrianN 6y ago
    Unless you work on trivial codebases you never stop learning. The code changes faster than you can keep up. It's a constant overhead for everything you do.
  - viraptor 6y ago
    There's no "duration". There's "what's the proportion of time you'll spend learning". Unless you have a very repetitive job, it will never go down to 0. It will just move towards it over time. And the rate of change depends on the person as much as on your internal structure, documentation, scope, etc.
  - nicoburns 6y ago
    This depends greatly on both the Seniority of the position and the complexity of the code base in question. Generally jobs I've worked have expected it to be on the order of 1-3 months, although I've found it hasn't always taken that long in practice.
tudorgirba 6y ago
This is quite interesting. I think we first have to talk about it at all. Doing that, we can learn how to optimize this part of the work quite significantly. But, would you like to detail what specifically you find hard?
agumonkey 6y ago
Recently on reddit there was a thread, here's the catch 22 that was unearthed: - if you're slow and careful, you're not worth your salary - if you're skilled and finish fast, that job was easy and not worth being paid a lot
- ehnto 6y ago
  You can really shoot yourself in the foot when freelancing with this caveat. The faster you are the less you make. I try to charge more because I do move pretty quickly, but I have been replaced by someone "A third of my cost" more than once. If you took the triangle for "Fast, good, cheap" and graphed the market demand for each, my gut feeling is that "Fast, cheap" is the leading demand by a long margin. To someone hiring a freelancer, "Fast, cheap" looks close enough to "Fast, Good"
  - rorykoehler 6y ago
    I've done some contracts where they thought it was a good idea to hire 20 interns before they hired any senior devs....
    - agumonkey 6y ago
      let me guess they started with 10 and then thought the solution was to add 10 more ?
    - Aeolun 6y ago
      Well, they certainly got what they paid for.
  - chrisweekly 6y ago
    Yep. This is why experienced consultants tend to aim for value-based pricing / project-billing, and avoid hourly when possible. Otherwise the incentives are all kinds of screwed up, even adversarial.
    - agumonkey 6y ago
skohan 6y ago
I think the best approach is not to be apologetic about it, and just treat it as part of the job (which it is). For instance, when you're talking about time/effort estimates, if you include the time it's going to take you to get onboarded with a new system, this is a sign you are more professional, not less.
- tudorgirba 6y ago
  I am not saying we should be apologetic about it at all. However, I am saying we can improve the effectiveness of the time we spend by an order of magnitude without much effort. We just need to want it. Interestingly, I also observed that solving problems without reading code leads to increased happiness, too.
  - pdimitar 6y ago
    I completely agree but currently, the way things are, we'd need very intelligent tooling that would be able to parse an entire project and give you some meaningful insights -- in order for you to have a shorter and more impactful onboarding. Thing is, nobody wants to produce such tools for free. Plus, they'd be a huge competitive advantage so even if a company invents such a tool they're very likely to use it for their own gain and not to help the entire programming area at large.
    - cxr 6y ago
      The choice of what to treat as bedrock is essential to the parent's comment remark that, "We just need to want it." The notion that a person or a team should be able to use whatever development methods and architectural style they feel like coming up with at the time and then throw it into intelligent tooling to figure it out—rather than, say, spending a little more time learning another paradigm that doesn't require general artificial intelligence to be a solved problem—is something that qualifies as wanting something but still not wanting it bad enough to do anything about it. Consider a closely related topic: source control. Nowadays, not using any form of control sounds crazy, but there was a time when that wasn't the case. What was standing in the way? A subset of working developers who just wanted to code without having to think about the task of systematically capturing a record of a codebase's history. But having a reliable, exhaustive record of changes is more useful than not having it, and the default stance today is that you need to use source control. What did it take to get here? Programmers getting over themselves and putting in upfront work to attain a level of competence where basic source control operations are natural. The tools that the author has created and the work they're doing is in "clearly better than what many people are doing now" territory, but it's completely unworkable so long as programmers are unwilling to get over themselves and keep opting instead to just do things the way they've always done them.
smcleod 6y ago
I've been struggling on and off with this for the past few years since moving into consulting after 15~ years of permanent (platform/ops/automation) engineering roles. Often the most difficult situations are not complex due to the use of some advanced technology or business need - but instead because of the sheer amount of components in play that you need to understand in order to add any value. The ramp up time just to understand WHAT components make up a given system let alone HOW they work seems to have shot through the roof over the past 5 or so years. With once monolithic systems being broken down into distributed microservices, service meshes being widely deployed, everything-is-an-API architecture and other good things - an unfortunate side effect (when combined with seemingly growing expectations on engineers to be 'full stack') is that cognitive load has shot through the roof. While compared to 10 years ago - it does seem like most systems have better uptime - I'm not convinced they're easier to support and aren't over-engineered most of the time. Edit: spelling, grammar (sorry it's midnight and I'm falling asleep)
- SamuelAdams 6y ago
  If your distributed microservices require several to be updated at a time for every change, are they really separate services? Isn't the entire point of a microservices architecture to reduce the cognitive load with understanding how everything in the system works? You simply need to learn endpoints, not inner-workings. Take Uber for example: post API 1 for calling a ride, post API 2 for payment data, post API 3 for reporting a problem. Unless your business requirements change drastically every 2-6 months, then it doesn't matter what architecture you use - you'll have to redo most of the stack in a monolith or distributed microservice arch.
  - potta_coffee 6y ago
    I call this "tightly-coupled-and-decentralized" and I hate it because it involves all of the pain of microservices with none of the upside.
  - smcleod 6y ago
    I didn't say anything about needing to update multiple at once, sorry if I gave that impression. Was just ranting about what I've seen in general.
pdimitar 6y ago
On my last job -- which I do regret somewhat for losing -- I failed at meaningfully delivering that message. There were SO MANY things to figure out, and I had no experience in Kubernetes (and only surface experience with Docker, Tilt and Helm) yet I was expected to be productive in 1-2 weeks after onboarding. The main reason why I started taking too long in doing any tasks was that I grew more and more reluctant to ask questions. They were always answered extremely shortly and unhelpfully and left me with the impression that nobody cared to help me start becoming productive sooner. Also you were expected to hang out in a rather unofficial Mumble server the entire day if you have questions. What? Are we working remotely or are we simulating an office? Seems it was the latter. So anyway, I took the long route and started exploring a lot while working on my first tasks. Needless to say, this got me fired. I regret losing the very respectable salary but beyond that I am actually happy that it didn't work out. It's like, I get it, you guys are all busy, but if you took one or two weeks to hand-hold me every day then we wouldn't have a discussion at the 4th month mark about why am I so slow and that I have to be let go. It was rather sad because I kind of liked the guys in the team -- but they were not helpful and you were expected to wing everything yourself. Which is fine, AFTER you receive meaningful initial help. Which I never did. Sorry for rant. Reminded me of this HN comment (disclosure: not mine) which IMO nails it: https://news.ycombinator.com/item?id=25800104 https://news.ycombinator.com/item?id=25800104 But, on topic again: I wasn't able to express that message properly some of the places I worked at. There are people who were receptive to it (it == "you need to properly onboard people even if that means some of your business-critical devs work at reduced capacity for a few weeks") when I said it in the past -- and most are receptive to it in my current job as well -- so it seems it really depends on the people themselves and/or the culture of the company. I guess it's kind of like hiring: it's much more randomness than anything else.
- stopnamingnuts 6y ago
  If I'm imagining your experience correctly this exemplifies part of why we need to open up our culture. Also, I'm pretty sure I've been in that gig and it bites. I suspect you dodged a bullet even if you got grazed.
  - 6y ago
commandlinefan 6y ago
> What do other people do in those situations One thing that I've tried (to varying levels of success) is to use that time writing unit tests. It's visibly productive, nominally helpful, and incredibly useful in picking apart what's actually going on under the hood. The two biggest challenges I run into are managers (including engineering managers) who insist that unit tests are a waste of time and codebases that retard attempts to break things down to workable units.
goblin89 6y ago
This might seem like it’s purely about optics, but I do think being familiar with some terms to communicate the need to understand out the system you are working on as a consultant or employee while being professional about it can help a lot. A couple of such terms that I use[0] are “knowledge transfer” and “[initial or in-depth] audit”. Typically I’d be communicating with a non-technical decision maker on the other side, and if there’s an existing codebase (or third-party systems that need integration into what I build) I may request: 1. An initial audit before I agree to the larger body of work. Audit will require access to systems in question and the ability to talk to the people in charge of or using them. Initial audit may already warrant an NDA, but whether I can accept further work will ultimately depend on the outcome of this initial audit. The deliverable of the initial audit may be a brief document or a scope/statement of work. 2. Knowledge transfer or in-depth audit. If knowledge transfer is impossible, during the previous step I’m supposed to get a good understanding as to why (does the previous owner refuse to communicate? which factors have caused this situation?), and instead of knowledge transfer allocate billable time for an in-depth audit. There would be a separate deliverable of this step as well, which would include some diagrams or documents describing the systems in question. A separate deliverable is useful both to myself and to the customer (if they choose to hire someone else to work on this), and makes it clearer what the customer is paying for. [0] If there’re better alternatives, I’d be curious to hear (though I’m not holding my breath, responding to this thread 2 days late).

dstick 6y ago

They lie?

tudorgirba 6y ago
:) That is intriguing. What do you mean?
- WJW 6y ago
  You tell the managers that you will spend no time at all on figuring out the system because you are just that good. Of course, you will still need to spend some time on it. Hopefully nobody will look into it too closely, but even if they do, you can claim that that time was already part of the "fixing the problem" phase. Most managers will not look into the matter too closely, because if they find no wrongdoing then it was wasted time and if they do find it then they have to spend even more time to find a new freelancer. (And possibly take a reputational hit for hiring the wrong person in the first place)

chriszhang 6y ago

I have not faced this problem. I say that there will be a learning curve to understand the product before a new developer can start fixing bugs or adding enhancements. Managers have always understood it. For contractors too the learning curve is part of the deal. The contractors get paid by the hour when they are climbing the learning curve. Managers seem fine with it.

tudorgirba 6y ago
What is typically considered an acceptable learning cost / duration in your experience? I am not asking because I do not agree that there is a learning curve (we call it assessment), I am asking because I am curious what people expect.
- pan69 6y ago
  > What is typically considered an acceptable learning cost / duration in your experience? How long does it take to do a crossword puzzle or play a game of chess? As with everything, it depends.
- adrianN 6y ago
  Unless you work on trivial codebases you never stop learning. The code changes faster than you can keep up. It's a constant overhead for everything you do.
- viraptor 6y ago
  There's no "duration". There's "what's the proportion of time you'll spend learning". Unless you have a very repetitive job, it will never go down to 0. It will just move towards it over time. And the rate of change depends on the person as much as on your internal structure, documentation, scope, etc.
- nicoburns 6y ago
  This depends greatly on both the Seniority of the position and the complexity of the code base in question. Generally jobs I've worked have expected it to be on the order of 1-3 months, although I've found it hasn't always taken that long in practice.

tudorgirba 6y ago

This is quite interesting. I think we first have to talk about it at all. Doing that, we can learn how to optimize this part of the work quite significantly. But, would you like to detail what specifically you find hard?

agumonkey 6y ago

Recently on reddit there was a thread, here's the catch 22 that was unearthed: - if you're slow and careful, you're not worth your salary - if you're skilled and finish fast, that job was easy and not worth being paid a lot

ehnto 6y ago
You can really shoot yourself in the foot when freelancing with this caveat. The faster you are the less you make. I try to charge more because I do move pretty quickly, but I have been replaced by someone "A third of my cost" more than once. If you took the triangle for "Fast, good, cheap" and graphed the market demand for each, my gut feeling is that "Fast, cheap" is the leading demand by a long margin. To someone hiring a freelancer, "Fast, cheap" looks close enough to "Fast, Good"
- rorykoehler 6y ago
  I've done some contracts where they thought it was a good idea to hire 20 interns before they hired any senior devs....
  - agumonkey 6y ago
    let me guess they started with 10 and then thought the solution was to add 10 more ?
  - Aeolun 6y ago
    Well, they certainly got what they paid for.
- chrisweekly 6y ago
  Yep. This is why experienced consultants tend to aim for value-based pricing / project-billing, and avoid hourly when possible. Otherwise the incentives are all kinds of screwed up, even adversarial.
  - agumonkey 6y ago

skohan 6y ago

I think the best approach is not to be apologetic about it, and just treat it as part of the job (which it is). For instance, when you're talking about time/effort estimates, if you include the time it's going to take you to get onboarded with a new system, this is a sign you are more professional, not less.

tudorgirba 6y ago
I am not saying we should be apologetic about it at all. However, I am saying we can improve the effectiveness of the time we spend by an order of magnitude without much effort. We just need to want it. Interestingly, I also observed that solving problems without reading code leads to increased happiness, too.
- pdimitar 6y ago
  I completely agree but currently, the way things are, we'd need very intelligent tooling that would be able to parse an entire project and give you some meaningful insights -- in order for you to have a shorter and more impactful onboarding. Thing is, nobody wants to produce such tools for free. Plus, they'd be a huge competitive advantage so even if a company invents such a tool they're very likely to use it for their own gain and not to help the entire programming area at large.
  - cxr 6y ago
    The choice of what to treat as bedrock is essential to the parent's comment remark that, "We just need to want it." The notion that a person or a team should be able to use whatever development methods and architectural style they feel like coming up with at the time and then throw it into intelligent tooling to figure it out—rather than, say, spending a little more time learning another paradigm that doesn't require general artificial intelligence to be a solved problem—is something that qualifies as wanting something but still not wanting it bad enough to do anything about it. Consider a closely related topic: source control. Nowadays, not using any form of control sounds crazy, but there was a time when that wasn't the case. What was standing in the way? A subset of working developers who just wanted to code without having to think about the task of systematically capturing a record of a codebase's history. But having a reliable, exhaustive record of changes is more useful than not having it, and the default stance today is that you need to use source control. What did it take to get here? Programmers getting over themselves and putting in upfront work to attain a level of competence where basic source control operations are natural. The tools that the author has created and the work they're doing is in "clearly better than what many people are doing now" territory, but it's completely unworkable so long as programmers are unwilling to get over themselves and keep opting instead to just do things the way they've always done them.

smcleod 6y ago

I've been struggling on and off with this for the past few years since moving into consulting after 15~ years of permanent (platform/ops/automation) engineering roles. Often the most difficult situations are not complex due to the use of some advanced technology or business need - but instead because of the sheer amount of components in play that you need to understand in order to add any value. The ramp up time just to understand WHAT components make up a given system let alone HOW they work seems to have shot through the roof over the past 5 or so years. With once monolithic systems being broken down into distributed microservices, service meshes being widely deployed, everything-is-an-API architecture and other good things - an unfortunate side effect (when combined with seemingly growing expectations on engineers to be 'full stack') is that cognitive load has shot through the roof. While compared to 10 years ago - it does seem like most systems have better uptime - I'm not convinced they're easier to support and aren't over-engineered most of the time. Edit: spelling, grammar (sorry it's midnight and I'm falling asleep)

SamuelAdams 6y ago
If your distributed microservices require several to be updated at a time for every change, are they really separate services? Isn't the entire point of a microservices architecture to reduce the cognitive load with understanding how everything in the system works? You simply need to learn endpoints, not inner-workings. Take Uber for example: post API 1 for calling a ride, post API 2 for payment data, post API 3 for reporting a problem. Unless your business requirements change drastically every 2-6 months, then it doesn't matter what architecture you use - you'll have to redo most of the stack in a monolith or distributed microservice arch.
- potta_coffee 6y ago
  I call this "tightly-coupled-and-decentralized" and I hate it because it involves all of the pain of microservices with none of the upside.
- smcleod 6y ago
  I didn't say anything about needing to update multiple at once, sorry if I gave that impression. Was just ranting about what I've seen in general.

pdimitar 6y ago

On my last job -- which I do regret somewhat for losing -- I failed at meaningfully delivering that message. There were SO MANY things to figure out, and I had no experience in Kubernetes (and only surface experience with Docker, Tilt and Helm) yet I was expected to be productive in 1-2 weeks after onboarding. The main reason why I started taking too long in doing any tasks was that I grew more and more reluctant to ask questions. They were always answered extremely shortly and unhelpfully and left me with the impression that nobody cared to help me start becoming productive sooner. Also you were expected to hang out in a rather unofficial Mumble server the entire day if you have questions. What? Are we working remotely or are we simulating an office? Seems it was the latter. So anyway, I took the long route and started exploring a lot while working on my first tasks. Needless to say, this got me fired. I regret losing the very respectable salary but beyond that I am actually happy that it didn't work out. It's like, I get it, you guys are all busy, but if you took one or two weeks to hand-hold me every day then we wouldn't have a discussion at the 4th month mark about why am I so slow and that I have to be let go. It was rather sad because I kind of liked the guys in the team -- but they were not helpful and you were expected to wing everything yourself. Which is fine, AFTER you receive meaningful initial help. Which I never did. Sorry for rant. Reminded me of this HN comment (disclosure: not mine) which IMO nails it: https://news.ycombinator.com/item?id=25800104 https://news.ycombinator.com/item?id=25800104 But, on topic again: I wasn't able to express that message properly some of the places I worked at. There are people who were receptive to it (it == "you need to properly onboard people even if that means some of your business-critical devs work at reduced capacity for a few weeks") when I said it in the past -- and most are receptive to it in my current job as well -- so it seems it really depends on the people themselves and/or the culture of the company. I guess it's kind of like hiring: it's much more randomness than anything else.

stopnamingnuts 6y ago
If I'm imagining your experience correctly this exemplifies part of why we need to open up our culture. Also, I'm pretty sure I've been in that gig and it bites. I suspect you dodged a bullet even if you got grazed.
- 6y ago

commandlinefan 6y ago

> What do other people do in those situations One thing that I've tried (to varying levels of success) is to use that time writing unit tests. It's visibly productive, nominally helpful, and incredibly useful in picking apart what's actually going on under the hood. The two biggest challenges I run into are managers (including engineering managers) who insist that unit tests are a waste of time and codebases that retard attempts to break things down to workable units.

goblin89 6y ago

This might seem like it’s purely about optics, but I do think being familiar with some terms to communicate the need to understand out the system you are working on as a consultant or employee while being professional about it can help a lot. A couple of such terms that I use[0] are “knowledge transfer” and “[initial or in-depth] audit”. Typically I’d be communicating with a non-technical decision maker on the other side, and if there’s an existing codebase (or third-party systems that need integration into what I build) I may request: 1. An initial audit before I agree to the larger body of work. Audit will require access to systems in question and the ability to talk to the people in charge of or using them. Initial audit may already warrant an NDA, but whether I can accept further work will ultimately depend on the outcome of this initial audit. The deliverable of the initial audit may be a brief document or a scope/statement of work. 2. Knowledge transfer or in-depth audit. If knowledge transfer is impossible, during the previous step I’m supposed to get a good understanding as to why (does the previous owner refuse to communicate? which factors have caused this situation?), and instead of knowledge transfer allocate billable time for an in-depth audit. There would be a separate deliverable of this step as well, which would include some diagrams or documents describing the systems in question. A separate deliverable is useful both to myself and to the customer (if they choose to hire someone else to work on this), and makes it clearer what the customer is paying for. [0] If there’re better alternatives, I’d be curious to hear (though I’m not holding my breath, responding to this thread 2 days late).