7 ms·

So there are two issues with this: 1. If I were looking to hire someone and read this, I would immediately be turned off. Why? Because part of being an enginee

by cletus 6y ago

So there are two issues with this: 1. If I were looking to hire someone and read this, I would immediately be turned off. Why? Because part of being an engineer (or any employee really) is doing a bunch of stuff people don't enjoy doing. This includes: - Writing documentation - Writing tests - Fixing bugs - Talking to partners about a change/launch - Talking to lawyers - etc So I would be wondering: if you're signaling you don't want to do those things, that means someone else will need to do all that for your code, which is not great for them and tends to be much worse. Like you're basically saying you want to cherrypick the parts you enjoy and not give a damn about anything else. You might say you're only costing $1/hour but the risk of a bad engineer can mean you're still expensive or a loss. 2. You don't factor in the time cost of me or my team in onboarding you, dealing with you, dealing with your code and so on. That's a big part of the filtering in hiring. People are deciding if they can justify that time investment and the opportunity cost involved.

MichaelGlass 6y ago
Regarding your first point: I want to do those things if I'm convinced they help the "good work". I might not want to clean the dishes but I'll do it until I can delegate it.
teachingassist 6y ago
1. I agree the author hasn't emphasised those things. If I was in need of those things, I might not automatically engage with the author. But, you've given a list of what you don't like doing - that isn't a universal list. Given that the author asks to be deeply involved in a human-centred project, it is not obvious to me that they don't like or are not prepared to do these things.
- cletus 6y ago
  The specific list of things doesn't matter. It'll vary from person to person and project to project. The point is, there'll always be something. My point is that if you're signaling from the outset that you want to cherrypick those things then I, as your employer, don't actually know what you will or won't do. I don't know if you'll follow up on tricky-to-reproduce bugs (as an example) because that's "boring". That's just creating work and uncertainty in dealing with those issues.
  - groby_b 6y ago
    If you as an employer are not able to deal with the fact that different people have different preferences, you either are running a very small shop (2-4 people) which just makes that impossible, or you're probably not an employer that will attract people who aren't deliberately choosing a "cog in the machine" path. I want to be very clear: There's nothing wrong with that path. There's nothing wrong with wanting to employ people who follow that path. But making it clear from the outset that he's not going to be a match for you specifically is likely a feature, not a bug.
    - thebean11 6y ago
      This only makes sense if in aggregate preferences are proportional the amount of work in each area, which is not the case (documentation is the obvious counterexample)
    - slingnow 6y ago
      I think you're taking a very black and white view of this. For example, ANY shop, of ANY size, is going to have issues with tricky-but-hard-to-reproduce bugs. The parent comment is highlighting the fact that they can't be sure if this sort of prima donna is going to be willing to run that issue to ground, or if they'll put up a stink about it being "boring". Additionally, even if this person were working for free, there's a definite cost to foisting difficult bugs on your teammates. Do you honestly believe only "cogs in a machine" should be / would be interested in fixing that sort of issue?
      - plutonorm 6y ago
        "Do you honestly believe only "cogs in a machine" should be / would be interested in fixing that sort of issue?" No but there are many types of people for whom it has no motivational value. Like they'd rather watch paint dry. And that's their personality not something that can just be worked around.
    - bumby 6y ago
      I didn’t downvote but what I suspect the OP is saying is “I want to hire someone who will get done what needs to get done whenever it needs to be done, not just when it aligns with what they want to do.” Having just re-read Daniel Goleman’s book on emotional intelligence recently, one important aspect to high EQ individuals is having the ability to motivate themselves to do work that may be necessary, but not necessarily glamorous or fun.
regularemployee 6y ago
> is doing a bunch of stuff people don't enjoy I enjoy writing documentation and writing tests. To me, writing documentation is like teaching others about the awesome product / features we have built, and also the different technical tradeoff decisions we had to make. I can't grasp the mindset where an engineer builds something really cool that they are proud of, but don't enjoy talking about it / teaching people how to use it.
- jrockway 6y ago
  Explaining how you did the thing that you already did cuts into the time for building the next thing. The difficulty that people wrestle with isn't whether or not documenting something is valuable, but rather whether documenting that thing should cut into their sleep, recreational activity, or The Next Thing.
  - Kinrany 6y ago
    This had nothing to do with the topic: some people don't want to write documentation.
    - ipaddr 6y ago
      Most because translating code to english requires changing mindset.
    - ljm 6y ago
      Or aren't given a good reason to do it. I don't really enjoy writing tests at the best of times, for example, because I've never had the enjoyment of inheriting a readable test suite. Most of the time you're looking at coverage hacks that test the runtime and, hopefully, cover some behaviour, and you're lucky if they can give you confidence through a refactoring. Mocks and stubs and spies are helpful tools but I've lost count of the amount of times that the actual purpose of the test is faked without anybody realising it. But now, this time, there is a purpose and also organisational remit to change this situation and I'm going all in on rebuilding test architecture and writing examples of what we want to see. I'm actually enjoying something I never really enjoyed. So it is with documentation, or dealing with bugs, or tech debt, or anything like that. It's not really about want or don't want, but why... and if you're on board with the why then it's gonna be better for you than if you're not. That, of course, depends on solid leadership. So ultimately you're looking at how tight your org ship is.
fnord77 6y ago
I suspect dealing with this type of person would become a huge issue. This work request hints at overblown entitlement. I've seen these types in action, the relationship between this worker and the manager/other teammates can turn abusive. Also imagine the impact on morale of the other teammates when some primadonna gets the cherry picked work and everyone else gets the drudgery. Pay or not. Run.
- manquer 6y ago
  As opposed to the overblown entitlement seen from managers and leadership? Typically this kind of setup works best when working independently. However in my experience doing similar setup in tech and other industries, many team mates have been grateful to work and learn from someone who otherwise would not work in their org or team. It works other way around too, I would happily work in a team for much less pay if I can work with people I can learn from even if they do all the cool stuff. Also I think he meant what kind of project he will work in not what all he will do in that project. Even if he did mean it that way, it is no different than in many regular roles where Senior ICs anyway pick and choose work they wan and junior members get the grunt work .
throwawayboise 6y ago
Exactly. I hire you (and pay you) to do what I need to be done, not what you want to do. Of course we both look for a situation where there is a lot of overlap in these things, because that means you are a good match for the job I am offering. But it will never be 100%.
- DiggyJohnson 6y ago
  How does the experience of a consultant fit into this evaluation?
spartanliving4u 6y ago
Exactly. Most developers do not seem to understand the cost of onboarding, dealing with them, dealing with their code and so on
wpietri 6y ago
I don't read this as a signal he won't do the work. From his talk about the stuff he enjoys doing, I don't doubt it includes things that feel work-like. He just wants the work to be meaningful. That seems reasonable to me, and that's how I am. As long as there's some point to the work, I'm happy to do the tedious stuff all day long. I recently user-tested a job posting for a high-meaning job. [1] Some people were very excited by the meaning, and were strongly motivated to apply. Others cared very little or not at all about the purpose; they worked because they wanted money for other things. Both are perfectly valid ways to approach work, I think, but I would handle each kind of employee differently. [1] https://docs.google.com/document/d/1yNITCTtVh5qHPof12cSf5PWhDRNbSAvlz7joVa7Xxfs/view#heading=h.g6rdhty351q https://docs.google.com/document/d/1yNITCTtVh5qHPof12cSf5PWh...
- ftruzzi 6y ago
  Thank you. Writing tests and documentation or diving deep into debugging hard issues is what I consider part of "good work" (and that I have also enjoyed doing), and I can't wait to do good work. It just has to be compatible with the rest of life. It's mostly the way we work that has to change rather than the content of the work.
  - jka 6y ago
    Thank you for the thought provoking article and discussion. I like to imagine that there is a virtual priority queue of software tasks out there, waiting to be done. Some of it is feature development, some of it is detailed bug investigation, some of it is documentation, and some of it is user interface work. What might be incredible would be to declare your interests and skills and start picking from the priority queue, with appropriate rewards as you progress, and at your own pace, knowing that you're contributing back to important tasks of the day. Ideally with a social safety net to allow people to enjoy life and adapt to changing circumstances.
  - monoideism 6y ago
    It may be wise to explicitly describe in your post what you consider "good work", including tests, clean code, etc.
brightball 6y ago
I had a developer on my team at my last company who was like this. Avoid at all cost.
- jascii 6y ago
  What do you mean by "like this" and why in particular should that be avoided at all cost?
  - brightball 6y ago
    I can’t talk about it in detail yet. Short version, the rest of the team had to pick up all of the things that he wasn’t willing to do. It shifted more burden to everyone else for his benefit and created a terrible team environment.
    - tasuki 6y ago
      > I can’t talk about it in detail yet. So... don't? Are you saying ftruzzi is like a person on your team in your last company and should be avoided? I don't see why you think he'd be "like that", what that'd mean, or really what value your comment is providing. I personally would love to work with ftruzzi!
      - devtosales 6y ago
        His post comes across as arrogant / maybe even a little choosing beggar. He lists his very specific requirements for working with him which makes me think he wouldn’t fit into an existing system, he’s want the system to bend to his will and that might be at the expense of others. He comes across as thinking he is shit hot and that I’d be lucky if I were to hire him. Based on his blog post alone, I would not hire him. Two short stints as a dev and he thinks the world should bend around him... lol
      - brightball 6y ago
        I was commenting on this part of the post I was replying to. I had a person that fit this profile. > So I would be wondering: if you're signaling you don't want to do those things, that means someone else will need to do all that for your code, which is not great for them and tends to be much worse. Like you're basically saying you want to cherrypick the parts you enjoy and not give a damn about anything else. You might say you're only costing $1/hour but the risk of a bad engineer can mean you're still expensive or a loss.
cranium 6y ago
I don't disagree with your first point but I think much depends on a person work ethic and what it means to them to do a good job. An engineer worth their salt would understand that success is not only writing the fun bits but also: the tests to make sure everything works as intended, documentation for their failing memory and having other contribute, bug fixes because we can't have those laying around, ... As is, the signal is too weak to know if the person just wants a toy to play with (I doubt) or if they are ready for the full package because they understand it's how it should be done. Definitively a point to check thoroughly before hiring – but it would be the same for other candidates, right ?
travisjungroth 6y ago
Those aren't "issues" with his post. They're just reasons that you would hypothetically (you're not even hiring someone) be a bad match. That's it. Doesn't mean you're bad, doesn't mean he's bad, doesn't mean his post needs changing, doesn't mean your company needs changing. None of that. He advertised himself honestly and it's clear it would be a bad fit. If your concerns are onboarding process and talking to lawyers, you would be absolutely out of your mind to hire someone who says "I'll work on stuff that pleases me when I feel like it for little money. And no tech screens, please!". A better match is an owner-run tiny software company. "We have an open source Python client library. It needs type hints. Sound interesting? Here's a link to the repo and some docs. I'll give you $5/hr in ETH up to $100 for whatever you do by the end of Friday." Then on Friday afternoon you maybe have some type hints and pay out up to $100. I'm picking on your comment in particular, but it's crazy to me how much criticism this guy is getting. He wants to try something new, and so many people are telling him what he should be doing, or why being on the other side of this trade is so terrible. Let's just let them make up their own minds. Let's stop trying to cram each other into little boxes.
- tartoran 6y ago
  > Those aren't "issues" with his post. They're just reasons that you would hypothetically (you're not even hiring someone) be a bad match. That's it. Doesn't mean you're bad, doesn't mean he's bad, doesn't mean his post needs changing, doesn't mean your company needs changing. None of that. He advertised himself honestly and it's clear it would be a bad fit. Totally. If I retired early I'd still want to work on something. I was thinking the other day what I'd like my next job to be and it involves taking a pay cut, working on something meaningful where I can explore new things, work at my own pace (not exactly a lesser workload but when I want to), and having nothing to do with nonsense corporate structure and culture. Yes, startups are dogmatic in their own ways and would avoid those. Why am I still taking jobs like this from time to time? Because I didn't get there, I can't afford the pay cut yet. Wish me luck.
emrah 6y ago
Writing just tests is not ideal, but writing tests in general can be very challenging and interesting given that you need to understand what the code under test does and figure out (edge)cases to exercise/break it.
- actinium226 6y ago
  This is why you write the tests first!
dragonwriter 6y ago
> If I were looking to hire someone and read this, I would immediately be turned off. Why? Because part of being an engineer (or any employee really) is doing a bunch of stuff people don't enjoy doing. This includes: [...list of things that, as an engineer, I enjoy all of, as long as I’m engaged with the project, and none of which conflict necessarily with OPs requirements...] Sounds like you just read your own stereotype of engineers ans what they like into that. > You don't factor in the time cost of me or my team in onboarding you, dealing with you, dealing with your code and so on. Well, no, nor does he factor in the potential value of his work on the other side, either. He offers to do an interview and let you, as the hiring party, factor those things in by setting a pay scale, for which the only up-front limits he proposes is that the hourly rate must be positive. Typically, that’s how factoring in value and overhead works in hiring, the hiring party, not the hired party figures them in and decides if and at what rate to make an offer.
sanderjd 6y ago
The way I would sum this up is that it seems like this person thinks of their code as an asset rather than a liability. I think of code the opposite way around. It's not a perfect analogy, because of course the functionality of the code - along with all the documentation and processes to maintain it - is an asset, but the code itself is not the thing, it's just the thing that gets you to the thing.
vmception 6y ago
A lot of "flat organizations" have the issue you describe too: the engineers lack leadership and don't choose the unsexy work.
patcon 6y ago
I feel you've misunderstood his point. The stuff you (or anyone) perhaps doesn't like is stuff that someone else LOVES. I absolutely love writing docs and tests and fixing bugs, and would be willing to get paid less to work on public code that allowed me to spend what I consider the right amount of time tending to those things :) Putting this call-for-employers out there signals (at least to me) that he can be a a really good deal if the employer takes it to task to find his complement, instead of creating a scenario where the employer gets to delegate it all wholesale to one person, regardless of their goals for growth and enjoyment. It's upstreaming the concern, and just getting to work on the things he loves at a pay cut for the inconvenience of matchmaking
OJFord 6y ago
I'm reading your comment before TFA, but in doing so my reaction is Uh what? Interesting can include docs, tests, bugs, partners, lawyers - it's whatever the topic is that all that is the work around. Again, I haven't yet read TFA but I don't tend to think that people seeking 'interesting work' are looking (and I don't personally want) to just crank out code. In fact, can't we go further? Is there anything interesting about it if you can just crank it out? The interesting work in my recent memory has been about reading, learning, thinking; not cranking.
icedchai 6y ago
Yep. I've been in tech for 20+ years, everything from a junior engineer to CTO and founder of a small company. A lot of the work is pure drudgery. I'd say 10% to 15% is "interesting." Usually that doesn't last for long.
mlazos 6y ago
This is such a bad faith argument that’s putting words in the author’s mouth. We all just want to be motivated to come to work everyday and be working on a product that we find interesting. I hope everyone understands everything can’t be a toy project (I think people do understand this) and even if something is interesting or meaningful it will still involve some level of “bullshit work” - the stuff you’ve listed. Every job has a bullshit to fun ratio and I think the author wants a fun part that he’s interested in and a ratio that’s acceptable. Nobody expects that ratio to be zero.
deleted 6y ago
[deleted]

by cletus 6y ago

MichaelGlass 6y ago

Regarding your first point: I want to do those things if I'm convinced they help the "good work". I might not want to clean the dishes but I'll do it until I can delegate it.

teachingassist 6y ago

1. I agree the author hasn't emphasised those things. If I was in need of those things, I might not automatically engage with the author. But, you've given a list of what you don't like doing - that isn't a universal list. Given that the author asks to be deeply involved in a human-centred project, it is not obvious to me that they don't like or are not prepared to do these things.

cletus 6y ago
The specific list of things doesn't matter. It'll vary from person to person and project to project. The point is, there'll always be something. My point is that if you're signaling from the outset that you want to cherrypick those things then I, as your employer, don't actually know what you will or won't do. I don't know if you'll follow up on tricky-to-reproduce bugs (as an example) because that's "boring". That's just creating work and uncertainty in dealing with those issues.
- groby_b 6y ago
  If you as an employer are not able to deal with the fact that different people have different preferences, you either are running a very small shop (2-4 people) which just makes that impossible, or you're probably not an employer that will attract people who aren't deliberately choosing a "cog in the machine" path. I want to be very clear: There's nothing wrong with that path. There's nothing wrong with wanting to employ people who follow that path. But making it clear from the outset that he's not going to be a match for you specifically is likely a feature, not a bug.
  - thebean11 6y ago
    This only makes sense if in aggregate preferences are proportional the amount of work in each area, which is not the case (documentation is the obvious counterexample)
  - slingnow 6y ago
    I think you're taking a very black and white view of this. For example, ANY shop, of ANY size, is going to have issues with tricky-but-hard-to-reproduce bugs. The parent comment is highlighting the fact that they can't be sure if this sort of prima donna is going to be willing to run that issue to ground, or if they'll put up a stink about it being "boring". Additionally, even if this person were working for free, there's a definite cost to foisting difficult bugs on your teammates. Do you honestly believe only "cogs in a machine" should be / would be interested in fixing that sort of issue?
    - plutonorm 6y ago
      "Do you honestly believe only "cogs in a machine" should be / would be interested in fixing that sort of issue?" No but there are many types of people for whom it has no motivational value. Like they'd rather watch paint dry. And that's their personality not something that can just be worked around.
  - bumby 6y ago
    I didn’t downvote but what I suspect the OP is saying is “I want to hire someone who will get done what needs to get done whenever it needs to be done, not just when it aligns with what they want to do.” Having just re-read Daniel Goleman’s book on emotional intelligence recently, one important aspect to high EQ individuals is having the ability to motivate themselves to do work that may be necessary, but not necessarily glamorous or fun.

regularemployee 6y ago

> is doing a bunch of stuff people don't enjoy I enjoy writing documentation and writing tests. To me, writing documentation is like teaching others about the awesome product / features we have built, and also the different technical tradeoff decisions we had to make. I can't grasp the mindset where an engineer builds something really cool that they are proud of, but don't enjoy talking about it / teaching people how to use it.

jrockway 6y ago
Explaining how you did the thing that you already did cuts into the time for building the next thing. The difficulty that people wrestle with isn't whether or not documenting something is valuable, but rather whether documenting that thing should cut into their sleep, recreational activity, or The Next Thing.
- Kinrany 6y ago
  This had nothing to do with the topic: some people don't want to write documentation.
  - ipaddr 6y ago
    Most because translating code to english requires changing mindset.
  - ljm 6y ago
    Or aren't given a good reason to do it. I don't really enjoy writing tests at the best of times, for example, because I've never had the enjoyment of inheriting a readable test suite. Most of the time you're looking at coverage hacks that test the runtime and, hopefully, cover some behaviour, and you're lucky if they can give you confidence through a refactoring. Mocks and stubs and spies are helpful tools but I've lost count of the amount of times that the actual purpose of the test is faked without anybody realising it. But now, this time, there is a purpose and also organisational remit to change this situation and I'm going all in on rebuilding test architecture and writing examples of what we want to see. I'm actually enjoying something I never really enjoyed. So it is with documentation, or dealing with bugs, or tech debt, or anything like that. It's not really about want or don't want, but why... and if you're on board with the why then it's gonna be better for you than if you're not. That, of course, depends on solid leadership. So ultimately you're looking at how tight your org ship is.

fnord77 6y ago

I suspect dealing with this type of person would become a huge issue. This work request hints at overblown entitlement. I've seen these types in action, the relationship between this worker and the manager/other teammates can turn abusive. Also imagine the impact on morale of the other teammates when some primadonna gets the cherry picked work and everyone else gets the drudgery. Pay or not. Run.

manquer 6y ago
As opposed to the overblown entitlement seen from managers and leadership? Typically this kind of setup works best when working independently. However in my experience doing similar setup in tech and other industries, many team mates have been grateful to work and learn from someone who otherwise would not work in their org or team. It works other way around too, I would happily work in a team for much less pay if I can work with people I can learn from even if they do all the cool stuff. Also I think he meant what kind of project he will work in not what all he will do in that project. Even if he did mean it that way, it is no different than in many regular roles where Senior ICs anyway pick and choose work they wan and junior members get the grunt work .

throwawayboise 6y ago

Exactly. I hire you (and pay you) to do what I need to be done, not what you want to do. Of course we both look for a situation where there is a lot of overlap in these things, because that means you are a good match for the job I am offering. But it will never be 100%.

DiggyJohnson 6y ago
How does the experience of a consultant fit into this evaluation?

spartanliving4u 6y ago

Exactly. Most developers do not seem to understand the cost of onboarding, dealing with them, dealing with their code and so on

wpietri 6y ago

I don't read this as a signal he won't do the work. From his talk about the stuff he enjoys doing, I don't doubt it includes things that feel work-like. He just wants the work to be meaningful. That seems reasonable to me, and that's how I am. As long as there's some point to the work, I'm happy to do the tedious stuff all day long. I recently user-tested a job posting for a high-meaning job. [1] Some people were very excited by the meaning, and were strongly motivated to apply. Others cared very little or not at all about the purpose; they worked because they wanted money for other things. Both are perfectly valid ways to approach work, I think, but I would handle each kind of employee differently. [1] https://docs.google.com/document/d/1yNITCTtVh5qHPof12cSf5PWhDRNbSAvlz7joVa7Xxfs/view#heading=h.g6rdhty351q https://docs.google.com/document/d/1yNITCTtVh5qHPof12cSf5PWh...

ftruzzi 6y ago
Thank you. Writing tests and documentation or diving deep into debugging hard issues is what I consider part of "good work" (and that I have also enjoyed doing), and I can't wait to do good work. It just has to be compatible with the rest of life. It's mostly the way we work that has to change rather than the content of the work.
- jka 6y ago
  Thank you for the thought provoking article and discussion. I like to imagine that there is a virtual priority queue of software tasks out there, waiting to be done. Some of it is feature development, some of it is detailed bug investigation, some of it is documentation, and some of it is user interface work. What might be incredible would be to declare your interests and skills and start picking from the priority queue, with appropriate rewards as you progress, and at your own pace, knowing that you're contributing back to important tasks of the day. Ideally with a social safety net to allow people to enjoy life and adapt to changing circumstances.
- monoideism 6y ago
  It may be wise to explicitly describe in your post what you consider "good work", including tests, clean code, etc.

brightball 6y ago

I had a developer on my team at my last company who was like this. Avoid at all cost.

jascii 6y ago
What do you mean by "like this" and why in particular should that be avoided at all cost?
- brightball 6y ago
  I can’t talk about it in detail yet. Short version, the rest of the team had to pick up all of the things that he wasn’t willing to do. It shifted more burden to everyone else for his benefit and created a terrible team environment.
  - tasuki 6y ago
    > I can’t talk about it in detail yet. So... don't? Are you saying ftruzzi is like a person on your team in your last company and should be avoided? I don't see why you think he'd be "like that", what that'd mean, or really what value your comment is providing. I personally would love to work with ftruzzi!
    - devtosales 6y ago
      His post comes across as arrogant / maybe even a little choosing beggar. He lists his very specific requirements for working with him which makes me think he wouldn’t fit into an existing system, he’s want the system to bend to his will and that might be at the expense of others. He comes across as thinking he is shit hot and that I’d be lucky if I were to hire him. Based on his blog post alone, I would not hire him. Two short stints as a dev and he thinks the world should bend around him... lol
    - brightball 6y ago
      I was commenting on this part of the post I was replying to. I had a person that fit this profile. > So I would be wondering: if you're signaling you don't want to do those things, that means someone else will need to do all that for your code, which is not great for them and tends to be much worse. Like you're basically saying you want to cherrypick the parts you enjoy and not give a damn about anything else. You might say you're only costing $1/hour but the risk of a bad engineer can mean you're still expensive or a loss.

cranium 6y ago

I don't disagree with your first point but I think much depends on a person work ethic and what it means to them to do a good job. An engineer worth their salt would understand that success is not only writing the fun bits but also: the tests to make sure everything works as intended, documentation for their failing memory and having other contribute, bug fixes because we can't have those laying around, ... As is, the signal is too weak to know if the person just wants a toy to play with (I doubt) or if they are ready for the full package because they understand it's how it should be done. Definitively a point to check thoroughly before hiring – but it would be the same for other candidates, right ?

travisjungroth 6y ago

Those aren't "issues" with his post. They're just reasons that you would hypothetically (you're not even hiring someone) be a bad match. That's it. Doesn't mean you're bad, doesn't mean he's bad, doesn't mean his post needs changing, doesn't mean your company needs changing. None of that. He advertised himself honestly and it's clear it would be a bad fit. If your concerns are onboarding process and talking to lawyers, you would be absolutely out of your mind to hire someone who says "I'll work on stuff that pleases me when I feel like it for little money. And no tech screens, please!". A better match is an owner-run tiny software company. "We have an open source Python client library. It needs type hints. Sound interesting? Here's a link to the repo and some docs. I'll give you $5/hr in ETH up to $100 for whatever you do by the end of Friday." Then on Friday afternoon you maybe have some type hints and pay out up to $100. I'm picking on your comment in particular, but it's crazy to me how much criticism this guy is getting. He wants to try something new, and so many people are telling him what he should be doing, or why being on the other side of this trade is so terrible. Let's just let them make up their own minds. Let's stop trying to cram each other into little boxes.

tartoran 6y ago
> Those aren't "issues" with his post. They're just reasons that you would hypothetically (you're not even hiring someone) be a bad match. That's it. Doesn't mean you're bad, doesn't mean he's bad, doesn't mean his post needs changing, doesn't mean your company needs changing. None of that. He advertised himself honestly and it's clear it would be a bad fit. Totally. If I retired early I'd still want to work on something. I was thinking the other day what I'd like my next job to be and it involves taking a pay cut, working on something meaningful where I can explore new things, work at my own pace (not exactly a lesser workload but when I want to), and having nothing to do with nonsense corporate structure and culture. Yes, startups are dogmatic in their own ways and would avoid those. Why am I still taking jobs like this from time to time? Because I didn't get there, I can't afford the pay cut yet. Wish me luck.

emrah 6y ago

Writing just tests is not ideal, but writing tests in general can be very challenging and interesting given that you need to understand what the code under test does and figure out (edge)cases to exercise/break it.

actinium226 6y ago
This is why you write the tests first!

dragonwriter 6y ago

> If I were looking to hire someone and read this, I would immediately be turned off. Why? Because part of being an engineer (or any employee really) is doing a bunch of stuff people don't enjoy doing. This includes: [...list of things that, as an engineer, I enjoy all of, as long as I’m engaged with the project, and none of which conflict necessarily with OPs requirements...] Sounds like you just read your own stereotype of engineers ans what they like into that. > You don't factor in the time cost of me or my team in onboarding you, dealing with you, dealing with your code and so on. Well, no, nor does he factor in the potential value of his work on the other side, either. He offers to do an interview and let you, as the hiring party, factor those things in by setting a pay scale, for which the only up-front limits he proposes is that the hourly rate must be positive. Typically, that’s how factoring in value and overhead works in hiring, the hiring party, not the hired party figures them in and decides if and at what rate to make an offer.

sanderjd 6y ago

The way I would sum this up is that it seems like this person thinks of their code as an asset rather than a liability. I think of code the opposite way around. It's not a perfect analogy, because of course the functionality of the code - along with all the documentation and processes to maintain it - is an asset, but the code itself is not the thing, it's just the thing that gets you to the thing.

vmception 6y ago

A lot of "flat organizations" have the issue you describe too: the engineers lack leadership and don't choose the unsexy work.

patcon 6y ago

I feel you've misunderstood his point. The stuff you (or anyone) perhaps doesn't like is stuff that someone else LOVES. I absolutely love writing docs and tests and fixing bugs, and would be willing to get paid less to work on public code that allowed me to spend what I consider the right amount of time tending to those things :) Putting this call-for-employers out there signals (at least to me) that he can be a a really good deal if the employer takes it to task to find his complement, instead of creating a scenario where the employer gets to delegate it all wholesale to one person, regardless of their goals for growth and enjoyment. It's upstreaming the concern, and just getting to work on the things he loves at a pay cut for the inconvenience of matchmaking

OJFord 6y ago

I'm reading your comment before TFA, but in doing so my reaction is Uh what? Interesting can include docs, tests, bugs, partners, lawyers - it's whatever the topic is that all that is the work around. Again, I haven't yet read TFA but I don't tend to think that people seeking 'interesting work' are looking (and I don't personally want) to just crank out code. In fact, can't we go further? Is there anything interesting about it if you can just crank it out? The interesting work in my recent memory has been about reading, learning, thinking; not cranking.

icedchai 6y ago

Yep. I've been in tech for 20+ years, everything from a junior engineer to CTO and founder of a small company. A lot of the work is pure drudgery. I'd say 10% to 15% is "interesting." Usually that doesn't last for long.

mlazos 6y ago

This is such a bad faith argument that’s putting words in the author’s mouth. We all just want to be motivated to come to work everyday and be working on a product that we find interesting. I hope everyone understands everything can’t be a toy project (I think people do understand this) and even if something is interesting or meaningful it will still involve some level of “bullshit work” - the stuff you’ve listed. Every job has a bullshit to fun ratio and I think the author wants a fun part that he’s interested in and a ratio that’s acceptable. Nobody expects that ratio to be zero.

deleted 6y ago

[deleted]