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/1yNITCTtVh5qHPof12cSf5PWh...

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.

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.

I think I get where you are coming from and am quite tempted to start a discussion.

I'm one of three directors of a small IT company in the UK and I'm feeling more and more compelled to steer it towards more innovative and societally important things. We are very small in the grand scheme of things but you will have heard of some of our customers. I am a pointy headed boss (PHB) who runs Arch Linux on his laptop and has a 3D printer on his desk. I also have a hammer drill and a set of sockets on it at the moment. That's at home.

I could probably find some jobs for you but frankly I suggest you start your own firm/organisation, do your thing and get all the rewards in whatever form that means - may not be financial. You sound very close to having a vision. Focus on what you really want to achieve and do it.

If you still fancy a chat, I'm up for it.

He is 26yo, he clearly states he needs a job, he seems desperate or untenably bored. Not uncommon, to be fair, but this ad is sort of a Hail Mary... so I would NOT suggest him to start his own firm right now... hopefully, next year.

It may be wise to explicitly describe in your post what you consider "good work", including tests, clean code, etc.

Then I would very carefully reconsider the wording of your article. This article would discourage most recruiters and hiring managers I know.

"You will give me interesting or meaningful work"

To be direct: this sounds entitled. Lots of growing companies don't have the resources to babysit and hand feed work to engineers. They need driven, self motivated engineers who can identify problems and help identify solutions, create and drive projects in ambiguous circumstances, that serve the businesss. It sounds like you're disconnecting from the requirements of a business to succeed in a market. I've worked on teams who got the "only give me the interesting programming tasks" engineer and they are a rot to the company. Whether or not you mean it to, that's how this pattern matches for me. Lots of work isn't interesting and is hard to rate the "meaning" of, and successful teams and companies need this work to be done by the whole engineering team.

"I like Python. I don’t like PHP and Java."

I would omit this entirely, as the language isn't related to how meaningful the work is and contradicts your previous paragraph.

"No technical interviews or coding challenges"

Again I think this shows immaturity and not understanding the needs of a business and hiring. Technical interviews do indeed have all sorts of problems, and they're generally the lesser of the evils of technical interview styles. Not every company has the luxury of "let's hire this person to figure out if we like them" and not every engineer has the luxury of "I'll do an unpaid take home that takes up my time instead." Onboarding takes time for lots of teams in a business, and getting up to speed on the domain of the business is an investment for everyone. Who you hire is one of the most important decisions a business has to make. Having a technical interview process of some kind is important, even if it has challenges to be objective with.

"I will prefer payments in cryptocurrency"

Just my personal taste, this one is an irk to me. It's a sort of removed-from-reality "I don't care about your real world taxing and accounting needs, I like crypto." Most companies flat out won't / can't do this, so it's a weird request unless you're specifically looking at a crypto company.

The great irony of this post is it's all just things you want, and not really anything about you or your skillset. The things a hiring manager or recruiter would actually look for are completely absent from this post. There's a hint with contradictions that you're looking for a mission driven company, beyond that I don't understand the point of this article. It smells of "companies, come to me, I'm special" while immediately setting limitations like "I don't like PHP." The hiring managers I know would say "this person doesn't sound like they know what they're looking for in a company, why would I consider them?" It sounds like you've already checked out from your own responsibility of understanding a company and why you might like them.

Right. The key passage is under rule 1 from the article: “You will give me interesting or meaningful work.”

First, the author says interesting OR meaningful work. So even if it’s true that the developer won’t be interested in, say, writing documentation for a legacy steel manufacturer, this developer might be happy to do so for a good non-profit.

Second, the author never said documentation and the like weren’t interesting. Perhaps that’s true, but Francesco merely wrote that he prefers Python over PHP and had a few industries he thought were interesting.

We all have skills and industries were interested/not interested in. And I think we and Francesco generally recognize some unpleasant work must be done in any field.

> He just wants the work to be meaningful.

well, he just slid down to "more unreasonable" with that clarification :) I can understand a "great coder doesn't want to write documentation" broadcast message, but if you want meaningful work to your standards, it's really on you to find the companies doing it and apply to them.

I would extend the common good advice to employees to this applicant: Offer to your manager solutions to problems, rather than just complaining about problems; managers have enough headaches, what they ache for are helpful employees; this also applies to hiring managers, so find a hiring manager who will want you, don't make him find you.

Then it sounds like you're in the second category I describe above, not the first.

Personally, I'd be unlikely to hire somebody in the "great coder who won't write documentation" category. But I'm happy to help a mission-oriented person find the right thing for them, even if it's not with me. Right now I'm also going to a great deal of effort to find the right people for a role.

And I don't particularly ache for helpful employees. What I want are people who care enough about the problems to think deeply about them and find approaches to solving them that I might never have come up with. And then are intrinsically motivated to see them through. If in that process they come to me with problems, that's great. Solving employee problems so they can get stuff done? That's my job.

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.

> 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.

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.

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 .

> 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.

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.

Personally, I'd rather not immediately jump into building the next thing. After having worked on any significant project, I find writing documentation helpful on a selfish level: I use it to wind down and let my brain idle for a while. I don't think it's a good thing to go full tilt from building one thing to the next. It's good to pause in between, appreciate what's been accomplished, reflect on lessons learned, and take a well deserved break. I find writing documentation an excellent vehicle for that.

What??

I look at it like this: explaining how you did the thing is part of doing the thing, so it's not complete until it's explained well enough for whoever your audience is. Not writing documentation cuts into time for doing the thing, i.e. cutting corners.

This had nothing to do with the topic: some people don't want to write documentation.

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.

Most because translating code to english requires changing mindset.

The problem is documentation is a different skillset to coding. Spend enough time doing only documentation and suddenly you're no longer a programmer, you're a documentation writer.

I actually like writing tests and documentation however i end up hating doing it for many reasons

- If I am able to focus on code, documentation or tests, I like doing it. Writing tests is sometimes lot more challenging than writing the code it tests. However context switching to difficult. I hate having to switch between the three

- The pressures of delivery makes it quite difficult to allocate meaningful time for either without cutting into scope.

- If your team does not value both to either read docs or maintain tests it become frustrating to be the only person doing it. If no one values it it can be demotivating.

- I have also seen teams either just focus on arbitary metrics like code coverage but not quality of tests or look at metrics like comment coverage/ number of lines of documentation, not whether docs are useful, how quickly someone is picking up by reading the spec, does it reduce bugs etc, quality and simplicity of language etc.

- It is a constant battle to keep both in up sync since i find it difficult to write code, tests and spec together. Once or twice a month I spend few days in trying to update both, which annoys me as they are out of date and I can only spend so much time on them.

it's almost like a form of solipsistic narcissism (the way The Last Psychiatrist describes it). Nobody else exists except as a supporting role. Why should they have to explain their genius work to anyone...

Or they are stimulated by new ideas and and general patterns? To those kinds of people writing how something that already exists works is supremely boring. It doesn't require narcissism

The difference is in whether you are willing to do the part that is not the most simulating but useful or whether you expect others to put up and do it instead of you.

And generally z others are as bored by that work as you, as simulated by new thing. Pretty often, the difference is not in how much you like boring parts, but in whether you are willing to do it anyway.

Or they just don't like writing? That's quite the leap.

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.

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.

I genuinely think that you are missing the author's point, and thus precisely not the target of this article.

In my reading of the article, I did not get the impression that the author is opposed to the specific, discrete components of the job that he found "lame".

If the demands of the article are truly impossible (socially and/or economically), then I believe that is the *point*, not a criticism of this post.

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.

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.

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)

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?

"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.

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%.

How does the experience of a consultant fit into this evaluation?

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

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

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 ?

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.

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

What do you mean by "like this" and why in particular should that be avoided at all cost?

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.

> 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!

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.

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.

> 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.

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.

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.

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.

This is why you write the tests first!

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.

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