Hacker News new | past | comments | ask | show | jobs | submit login
Hire me and pay what you want, just give me interesting work (truzzi.me)
507 points by ftruzzi 57 days ago | hide | past | favorite | 408 comments

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.

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.


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.


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.


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.

If you expect the interesting work to land in your lap you are either one of those people that redefine (maybe invent) entire fields of research or you're incredibly lucky. In other words, your work speaks for itself and people want to give you more of it. For most people we need a job in order to keep up with the rising costs of living.

If, however, you're like 99.99% of people and are good at what you do then you'll have to find what is interesting about the job. I've worked at a company that replaced clipboards with iPads in a factory. If all it was to me was a form-builder application and the technology under it I would have been turned off ages ago. But I was incredibly curious as to why the product as successful and growing, what our customers liked about it, and I pushed for developers to visit the factories and see how people used the app. The results were quite surprising and it fed out team with dozens of ideas.

Technology for technology's sake is fun for a while but will eventually bore you. It helps to have a reason to work on what you do. Which I think is part of what OP is saying but I think you can find the reason in a "boring" job as well. You just have to be curious and look for it.

Although avoiding working at feature factories where the developers are just cogs in a Kafka-esque Agile Machine is a whole other can of worms. The OP's strategy seems like an interesting way to avoid it. Best of luck!

It doesn't have to be interesting in a field defining level always. Purely technical problems interests some people too, it really depends on the person finds finds interesting and boring as your examples describe. You can find it, or as OP is trying it can find you .

I am not sure I agree with premise that most of us have put up with the dullest job to keep up with cost of living. There are plenty of tech jobs out there beyond the valley, in other parts of the world which are definitely interesting and pay reasonably above cost of living requirements.

It is not so clear cut to me that mpst don't have some freedom in choosing what kind of work to do without going to the highest paying boring one, tech is not minimum wage sector where we have little to no choice and limited in mobility. The cost of living is not that high that we have zero choice, other sectors don't pay as much in the same areas and they are able to manage after all.

>you'll have to find what is interesting about the job.

This reminds me of the advice that one needs to cultivate their passion rather than expect to stumble upon it.

Funny, the comment reminded me of a slightly different piece of advice which goes like this: Decide not what passion you should follow or what goals you want to achieve but what problems you want in your life.

I think the first time I read about this idea was in this article by Mark Manson: https://markmanson.net/question

Random idle/curious question: "a factory" doesn't describe the roughness of the working conditions, but assuming a baseline of a mildly industrial context, how did you mitigate the risk of dropped or damaged iPads?

(As an aside, it's kind of a pity that there isn't a standard drop-proof tablet out there that can be deployed without thought in these kinds of situations.)

Date: Dec 2020

Header image: stock photo showing tablet running Windows XP and Java application

Article relevance to market: 101%

In all fairness, this is *closes ad popup* an interesting page, thanks.

Probably iPads encased in rugged cases / mounts.

That was what most of our customers did for on-the floor tablets.

They would also use mounted TVs and have their scrum around our app's dashboard page which was something none of the developers had thought of.

I’ve been on the receiving end of similar requests before.

“I’ll work for free or nothing if you let me do what I love under the umbrella of your organization because I love it so much.”

I did one or two agreements like this and then stopped altogether. The individual would start their work, others would start to depend on its existence and the individual would leave in a matter or weeks or months because something else better came along for them. There was no incentive to keep the relationship going over a longer term. My organization just wasn’t setup to see any upside to short lived but high quality team members.

Is there anyone out there who does work agreements like this currently and benefits from them? Would love to hear more details. Perhaps that feedback could help Franceso with his pitch.

Franceso please come back in a week and let us know what kinds of offers you received. Will be very interested to see where this goes.

I have some similar experiences. Especially with people saying "let me do what I love" or "give me a position where I can learn new things".

People like variety - the initial love doesn't last long. After a few weeks/months it gets boring and repetitive. Learning the shiny new tech is only fun until you you've figured out how it works, but the project doesn't end there and you have to deliver a product in the end. But for most people who exclusively want the "position where they can learn new things" fixing the bugs and doing the finishing touches is no longer fun once they've figured out how the underlying tech works - they leave for the next position where they can learn another shiny new tech and you're left with a half-finished project (usually with subpar code quality because this was the first project they did using the new tech).

But this is my personality. Given repetitive work I become depressed quite quickly. I say this as a 40 yo who understands themselves well. Yes I can struggle through, but this career has brought me to the brink of suicide on two occasions. Working to the grind of an agile development cycle is poison to me, it drains all color from the world. I'd rather break my bones. Where is the space for people of my color? Who dry up and die if asked to write boiler plate crud code and unit tests for fizz buzz UI elements.

Unless I'm solving a problem that's genuinely intellectualy stimulating then I have 0 interest in coding.

Most of us hide the misery because we know that the only outcome of airing it is dismissal either in the short or the long term.

There is no role for us in this career but having sunk so much time into it we have no other option but to keep on going.

You have to do your own thing ... usually that's bad advice but for people with the temperament you describe I think it's reasonable.

Also a lot depends on expectations and finding good partners. In a previous job I worked with another guy as a team. I would start projects and get an MVP out and delivering value - then move on to the next thing. He would go through and essentially rewrite them to be high quality, solidly engineered products, well integrated with the rest of the stack.

We both got to do what we enjoyed and were good at: I am very fast at breaking new ground and delivering new value, and find engineering a bit boring. He was very good at improving existing systems, but too slow and plodding to try out new ideas effectively.

i have the unmet rambling dreams of the first person, and the anxiety-driven perfectionism and revulsion to poorly written code of the second person... so i'm unhappy thinking about unfulfilled ideas, unhappy writing new programs, and unhappy fixing old programs.

"i can only do so much and of course it's never enough"

i want the perfect programming language, the perfect gui library api and theme, the perfect program, the perfect ide... and i can't accomplish a single one

and of course C++ is an all-devouring Cthulhic monster that does everything but poorly, Rust has immature gui libraries and doesn't fully align with my values and desired features (I want linear typing, strong typedefs/subclasses of integer types, polymorphic variants/anonymous unions, prioritizing iterator generators over async), qt is basically legacy code and Qt Widgets is mostly unmaintained but difficult to fork (to build, create Windows installers, and convince Linux distributions to accept behavior-changing bug fixes), and my personal dream project (https://gitlab.com/exotracker/exotracker-cpp) is vaporware no matter how much i burn myself out making it (trying to both explore new ideas, and engineer them well, at the same time).

Well said. This is why engineers who know how to finish the last 10% are truly valued by good colleagues and managers.

I don't think so, most teams never do the last 10% on any project ever. They pick the low hanging fruit with the first 80% and if they are thorough they might bring it up to 90%, but 100%? I've never seen such a software project.

I'd say that Total Commander is very close to 100%.

TeX82 as well. From https://en.wikipedia.org/wiki/TeX#TeX82:

> Since version 3, TeX has used an idiosyncratic version numbering system, where updates have been indicated by adding an extra digit at the end of the decimal, so that the version number asymptotically approaches π. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. The current version of TeX is 3.141592653; it was last updated in 2021.

And those who aren't like that by nature are much less useful I suppose?

Personally I love doing the finishing touches but I'm usually not allowed to because the feature or product is considered good enough. It's hard to find a job where everyone really care about quality.

I feel like this is me with side projects sometimes. Do you have any tips for staying on target?

I generally don’t have this issue in my actual job.

For side projects, I think there is some value in not being concerned about finishing them. If you're doing them for enjoyment then they shouldn't feel like a job.

But I find defining exactly what done will be on a personal project helps a lot to get completed. I define features are the minimum necessary and once I reach those features I immediately switch to trying to release it. Releasing is always a lot of work so it's easy to put it off forever while constantly iterating on a product. But actually releasing gives a good feeling of accomplishment.

Here's a couple of thoughts. Sometimes not following through might not be about feelings or at least not directly. If you do a project to learn some new tech then the project is not about what it does but about how to do it. So make sure you pick side projects that you think need doing. Find a partner or a group to do the project with or create some way that you make yourself accountable for it's completion. Who are your projects for? If it's for yourself, then is it something you really want or maybe just an idea? If it's for somebody else or some group then create a connection to that group or some people so that you know who you're making it for and include them in the project. That way you have someone to deliver it to and to continue to support. Lastly, maybe it's a decision issue. Maybe you just never really completely decided to do it. How do you know when you've decided to do something?

When I get stuck on projects that are very meaningful to me, I chip away at the pieces I don't want to do and allow myself to take as long as I need to complete them.

When I get stuck on projects that are not so meaningful to me, I reduce scope.

The obvious elephant in the room is how can someone afford food and rent while working on $1 or whatever. If I was a hiring manager I would assume one of 3 things: 1) He is independently wealthy, 2) He lives in a van, or 3) he really expects $50/hour and this is some sort of bait-and-switch strategy.

I'd also suggest people making these requests to try and expand their interests to make themselves more rounded and valuable. For example I'm totally the kind of person that likes to jump from one thing to another cause I like the challenge and I get bored quick otherwise. But instead of jumping ship cause the challenge is gone I try to find a different closely related challenge.

Here's a couple of techniques for anyone looking to do the same:

1. Look at the 'supply chain' of inputs and outputs from your problem area. Are there new inefficiencies somewhere in the stack that you can dig into and solve, and leverage your new knowledge. This could mean a whole new area of things to learn in order to investigate or solve those problems.

2. Never accept the status quo. Every time you're asked to do something else, treat that as an opportunity to find one thing that you can improve in the related systems. Here you'll learn the new system, but you'll also learn how to pick worthwhile areas for improvement.

3. Be reflective and review what you found interesting and what you didn't and dig into the ones you didn't find interesting. Ask yourself why you didn't like things; was it cause it was too difficult to pick up? was it cause you don't like people problems? was it just too big a problem to tackle? Dig in more and ask why again (like the Toyota 5 Whys). Eventually you should be able to find a problem area that you can clearly define and potentially work on to improve.

I realize these 3 techniques won't necessarily lead to 'cool tech problems', but that's kinda the point! If you can get yourself interested in solving related problem areas, you'll find you pick up a lot of useful knowledge and value that you can apply in many other areas you wouldn't have first thought of, all while always jumping between things and not getting bored!

(edit: formatting)

I don't have anything to add to this, only to say thanks - that's decent advice. If you do X, you can learn about Y, and apply it to Z.

If you have a broad interest there's like a million different ways to pivot and branch off to learn different things.

Seems like a weird idea to me anyways, to offer to work for very little money or even nothing, as long as the work is interesting.

To me it seems that time is much better spent on a fun personal (side) project. And who knows ... maybe the side project will earn some income in time.

I did something sort of similar. There are limits to what you can do with a side project, and joining a company gets you access to other people with different skill sets from yours.

In my particular case after finding a good fit with a small startup I told the CEO to just pay me as little as he could reasonably justify and make up the rest in equity (which I was fully aware would likely be worthless). In a different framing, I was "spending" my missing salary by "hiring" some people to do the work I wouldn't want to do - pitching deals, forming business relationships, and negotiating contracts to get me the data that I actually wanted to work on.

But that's not the idea is it? The idea is to define the terms, and see what the bids are. Perhaps, if the bids are too low, the decision would be to 'pay oneself' (spend from savings) while working on said side project. But the point is simple - an attempt to find a union of two interests at a price that makes sense.

Same, sometimes people volunteer to help me code https://coursemaker.org for free because they like the idea. In one case this has worked out well. But in a couple of others the engineers have vanished quite fast. Sometimes I wonder if I made a much more serious effort to onboard/document/give ownership then would they stick with it. What do you reckon - how was the onboarding in your case?

A generic advice: 15 years ago I might have felt similarly, but now I think it's the other way. If you want interesting work, demand higher pays and try to get into such positions.

When you're highly paid you will get more interesting work, because the company will see you as a valuable asset that should be working on "hard" things. When you're being paid a penny, the company will think you're worth a penny and will assign you menial tasks.

BTW I didn't really live up to my own advice, either. ¯\_(ツ)_/¯

It's not just about pay it's also about earning respect (by delivering good and making valuable contributions to the team) and your relationship with your manager. My manager literally asks me, "What do you want to work on?"

In my experience it's more to do with whether you've proven you can do a particular type of task, and do it well. Project managers will then give you that type of work because you're a safe bet.

I've worked with people in the past who felt like they weren't getting any of the interesting jobs. Their solution was to go to their manager and complain that they were being passed over. But if you're not proven at a task, then you're a risky bet, and you'll only be picked if there's no other option.

My advice to those people (and this won't necessarily work in all industries) is to make yourself less risky. Share a weekend project with the team where you worked on the sort of problem you find interesting, and make sure it's good enough that it gets people's attention. If you can make some important people say "wow, I didn't know you could do that sort of thing!" you'll probably notice you start getting more interesting jobs after that.

This is what I found as well. At high pay, you may be getting into building MVPs and prototypes - these don't require "boring" things like extensive testing or documentation. The board will see that their idea works and then only "boring" part is hand over to dev teams to "productionise" it.

It's almost funny how this is the polar opposite of what you often want when hiring. You're hiring to add manpower to tackle the kind of unexciting tasks that you don't naturally find people drawn towards from your existing team (and then, people's responsibilities expand, or they turn 'boring' work into interesting work by redefining the problem or attacking it on a deeper level).

When you have a growing business, money is probably not not the primary concern, but the last thing you can afford is someone on the team being picky about which tasks are beneath them.

No judgment here, I understand OP's sentiment, but I cannot remember any situation in my career where 'hire me, I only work on what I find interesting but it'll cost you comparatively little' would have been an exciting proposition (on the hiring side).

I'd put it a bit differently than the OP - for me interesting and meaningful work means that it's actually benefiting society in some way. That would mean that even the 'boring' aspects would have some kind of meaning ("we're trying to cure X" or "We're working to help solve global warming"). Too much work now is just trying to sell stuff to other people, get people to click links, get people riled up so that they're engaged with some social media platform - it's not helping us as a species.

Definetely. Making a rich guy get richer is boring. Helping the planet be a better place sounds interesting.

Apart from hedge funds and quant trading firms, I think there is a lot of that sentiment be projected onto many software engineer jobs (at least, imo

Hire me and provide a steady stream of well-defined work is what I'd settle for.

I'm currently about to abandon a 12 month contract about 3 months in because it's become apparent that the company didn't actually want a "DevOps" position, and I was hired as part of some incredible misconceptions about the regulatory environment they operate in by the managers who created the position.

The problem isn't "being bored" for me, it's feeling like time is passing slowly. I don't really care what if at the end of the day it's a surprise that it's all of a sudden 5pm.

If a company is trying to hire people to do the work that current employees don't want to do then it sounds like they have already hired the wrong people.

As a company grows, all sorts of new problems open up that your current employees might not be a great fit for. For example, you might not need a DBA when just starting out, but when your database reaches a certain size it might make sense to hire one. Or you might need to hire a middle manager once you reach a certain size - but all of your initial hires prefer individual contributor roles. Or maybe you need someone with a strong background in security to be able to pass an audit.

It doesn't mean that you hired the wrong people. Just that your needs are changing.

As others have suggested, have you considered joining an opensource project?

- https://github-help-wanted.com/

- https://up-for-grabs.net/

- https://www.codetriage.com/

- https://opencollective.com/discover

I'm sure there are organisations that would love to have some technical volunteers. Maybe try and find NGOs you believe in and send them a private or public message?

Or, if you want to get politically involved in your country, you could try and find yourself a political party you believe in, ask them if they have any technical tasks, and see from there.

Yeah I don't know why someone would essentially give away their talent and time to a for profit corporation. There are so many better alternatives

Well, money.

Money... at $1/hour?

I have nice boring job. Few years ago I was upset with the boring part. But with kids and mortgage I don’t really care anymore. I am very happy to be paid more than a manager in a small company being only individual contributor in big Corp. I also have approval to sell my hardware from big Corp. So I can explore new things with commercial potential without a fear. Life is good.

Stability and work life balance are terribly underrated.

I'll take a boring stable 40 hour a week job over a fun job that somewhat frequently requires 50+ hours. Time is the only thing I cant get back. Money really is just a number after a certain point.

Why do you still work for others if money is just a number at this point? I worked for Google for a while and quit to do my own projects once I had enough money that I felt it didn't matter any more.

I'm not exactly at that level yet. I couldnt stop working forever. But I realized that making money isnt all that difficult and its really a make believe number after a certain point.

What kind of projects are your own projects?

For me, interesting and fulfilling work is hardly work at all. 50 hours of fulfilling work essentially kills two birds with one stone (intellectually fulfilling, and pays my income), as opposed 40 hours at a job that I don't care for, but at least it's only 40 hours and pays alright, and then I have to try and sate my mind alongside everything else I want to do outside my working hours.

There's nothing worse than being stuck in a job where you're watch the clock, waiting for it to strike 5 PM.

Right. I guess I'd be in the same boat if I found something truly interesting. I've had interesting projects but I find that the fun parts of most projects are short. Worse most companies are not going to be able to provide you with something fulfilling for very long.

Depends on personality. For some its poison and burnout and depression are not far behind.

Yeah, personally having a large chunk of the day be simple tedious tasks I don't have any control over makes me depressed and every day becomes a fight to keep the mental breakdown just out of reach. I envy people who can stay sane in such environments, makes life a lot easier.

I feel that way about meetings. Boring tasks can be automated away if they have a pattern.

I may be conflating 'boring' with 'rote', but how do you think the nature of your work may affect your job security? This is something I worry about sometimes, because I find that the work I'm doing could eventually be de-valued or automated. Still, I very much appreciate your position as I'm in a similar boat.

Big Corp lost a big project few months ago. Big Corp will loose another one soon. I hope, I can get senior title before shit hits the fan. Contribution does not matter for the title, only employment duration is important.

However I am consulting a cool startup for free, do code reviews for them for free and could start immediately there with ~8% lower salary but 100% home office. That’s my plan C. Plan B is my own small hardware business selling Raspberry Pi based lidar and radar. I am not far away from the first product. I love these topics and compensate boredom at day job this way. As I mentioned, big Corp does not see interest conflict and I may sell these cool gadgets for wide Raspberry Pi community.

Work balance, and some reasonable freedom to self determine is pretty nice and likely more important for the stability in a long term working engagement than being "interesting" work.

After kids and mortage, you will be upset with the boring part again :(

not OP, but at that point I imagine the equation changes: stability becomes less important when you aren't the sole provider for a pile of people, and/or once cost-of-living goes down (e.g., paid off mortgage).

I was able to pay off my mortgage about a year ago (I am in my late 30s), and work has taken on a new aspect for me. I feel a bit more comfortable challenging the status quo and trying to take on more "interesting work". With that in mind, I am still attentive to the fact I need to maintain a sustainable career for another 25/30 years.

Many people in my circle are proud of paying off mortgages, so I kind of assumed by default that it is a worthwhile thing. But looking at the numbers I'm not so sure: it seems much better in current market to cash out as much as possible and let that money sit in an index fund. I guess the main issues are some risks with downturns and/or liquidity.

I completely agree that it wasn't the right financial decision, but I don't regret it at all. I grew up working poor and watched multiple people lose their houses (some crash related, others not). This gave me a fairly conservative risk tolerance regarding debt. I feel "lighter" without debt hanging over me.

The question that ultimately convinced me to just pay off my mortgage was "If someone gave you a house, free and clear, would you mortgage it to buy investments?". My gut reaction was "no, I would really like to have a free and clear house."

I have considered buying a second home to rent, but I have some moral qualms about exacerbating the housing crisis where I live. Furthermore, the stress of tenants isn't something I really want to deal with.

Everyone here has great points about maximizing returns, and I know I will have less money in the long run because of my decision. With that in mind, I am investing about half of my old mortgage payment, and the rest goes to the family vacation fund.

Just wanted to thank you for the comment and clarify I didn't mean to criticize your choices - my background is very similar and it's just a realization I've had after stepping back and trying to think without those constraints/influences. I also know many people who lost houses or struggled, some which actually did cash-out refinances but then unwisely spent the money on unnecessary luxuries. Those seem easy to avoid. Some may be harder to avoid, like when someone has unforeseen costs such as medical related bills. But in cases such as ours, it seems we are well enough off to have cash on hand to eliminate the mortgage; the question just becomes whether that is the best use for the money. It certainly seems a bad idea to just keep the cash on hand. The index fund returns have been very good for long periods of time now, so seem like a good low-risk option, given that they are liquid and can be redirected to a mortgage payoff at any time.

Edit: having said that the difference is not that large (3-4% for the 30 year note, vs. 5-10% for the market return). Also, while I didn't pay off my mortgage, I probably won't put even more money where my mouth is and refinance in order to invest the cash-out into a fund.

No criticism or offense taken at all! I think these discussions are incredibly valuable for the participants and observers to help them decide what they want to do if/when they have a pile of money in front of them.

A place to live which cannot readily be taken away from you carries tremendous practical value and existential comfort.

You're right. None of those people account for the time value of money. If I could get an interest only mortgage I would (where I literally pay to rent the money). There are so many better things I can do with a few hundred thousand dollars now.

If you have the money to pay off your mortgage, why not buy a second house with it and rent that out? Let someone pay your mortgage while you get the appreciation? Or invest it in something else?

If you do the math, renting almost always comes out ahead of owning, as long as you invest the difference in something that gains in value.

The main reason to own is for psychological reasons. It's great if you have kids and want a place for them, or yourself, to call home.

I think this statement is a bit strong. The price/rent ratio varies greatly between places and times. Around here it's between 30 and 40 years, that makes it very difficult to make money by borrowing to buy a place to rent out.

In such markets, the bulk of the ROI is not the rent checks, but tax savings and appreciation of the underlying asset.

Real estate looks a lot like the stock market anymore. People value companies on metrics beyond simple revenue, profits, and dividends. With RE, investors understand that wage growth in a region flows into housing at a compounding rate due to leverage and are capitalizing on it.

So long as Seattle or LA have companies that pay above average wages to enough employees, housing prices in those regions should continue to grow at a a rate somewhat relative to differences in wages. What constitutes "enough employees" seems to be relative to how constrained housing growth is. In LA, housing prices are driven by probably the top 20-30% of earners.

I think the part that needs to be factored into your analysis is the volatility/risk aspect. A mortgage may be relatively low ROI but it’s also relatively low risk compared to the market. E.g., maybe somebody has a certain percentage invested into low risk bonds. Maybe it makes sense to pare back some of that and put it towards their mortgage during a period when bonds are being crushed. Neither bonds or the mortgage return will compete with a general index fund in terms of return over a long period of time, but the index fund is in a different (higher) risk category

The 'mortgage return' will compete very well over a long period of time, especially if you ensure the comparison is fair. For instance, 15 years in, when your mortgage note is 60 to 70% of prevailing rent or lease, consider the return on that savings as part of the 'mortgage return' - because this is part of the return in the form of inflation hedge.

Right, the best financial decision is usually to take advantage of low interest rates, carry the debt, and keep the money in diversified investments.

Yes, there's always the risk of a downturn or recession/depression that ruins that plan. And beyond that, there is often a great psychological benefit to being debt-free, even if that's not the best financial decision.

One thing to keep in mind is that mortgage is the cheapest money you'll ever borrow. Low rates vs. other kinds of loans, and the interest is often the biggest tax deduction most middle class people have access to.

That reality is a property primarily of the present-moment.

Index funds don't always rise and property values sometimes fall. Interest rates are rarely this low. Leverage multiplies both the upside and the downside.

> and property values sometimes fall

While this is true in the short term, except for very rare exceptions, you'd be hard pressed to find a property in the United States that is worth less now than 30 years ago (which is the standard length of a mortgage). I don't know about other countries, but I suspect it's the same in any modern economy. Land is scarce, and no one is making more of it.

Agreed -- what I had in mind was the underwater loans of 2008. A house bought with leverage can occasionally look real strange in the short-term.

I think at that moment, what could work is contract work. A 6month~1 year contract. Finish the project, then take a vacation to travel

My first experiment with this certainly hasn't yielded the focused directed effort I was hoping to apply. I've worked permanent positions which felt a lot more like contract positions. At this point the main thing is for similar money I'm having to put a lot more effort into keeping track of my taxes.

>> No fixed hours, I will work when I want.

>> no daily stand-ups

>> Meaningful work means work that I care about

>> This whole thing is not about money, so what the work is about comes first

There is a profound mismatch between what this person is offerring and what anyone would want from a developer, or even the core requirements for effective software development. I'll pass.

I am most curious about the "no technical interview" part and "my work speaks for my skills" while OP's GitHub is just forks.

This all really reads in an uncomfortable way and I would never risk investing into somebody by guessing if whatever I need done, as a business, will be interesting enough for this person to put genuine effort into.

I feel like OP needs hobbies to get the fun/interesting itch scratched and then go back to being a "code monkey" like the rest of us, doing "boring" stuff to pay the bills.

I've been there myself before and the most valuable lesson I've learned is that motivation != discipline. Motivation comes and goes and if you base your productivity solely on that you will burn out. Being disciplined though allows to get the "boring" out of the way first, leaving lots of time to explore other interests.

> I am most curious about the "no technical interview" part and "my work speaks for my skills" while OP's GitHub is just forks.

On Github you have to fork a project first if you want to create a pull request. I randomly opened three of the forks and saw that he'd made pull requests for two of them.

I fully understand the way forks work - what I found troubling is that for somebody who is dying to do something interesting, for close to no pay, there seems to be little indication of them doing things out of pure passion/interest as is. For somebody expecting me to hand pick things that are super fun to work on there is not enough incentive/conviction for me to trust this person and/or invest any time into onboarding/managing them. That's literally why you get paid "the big bucks" - the employer can demand specific things without having to depend on your mood and attitude towards task A.

The only thing I can suggest to the author is what others have already said - go in to academia/research and volunteer your time to selected interests.

One scenario in which the author's attitude and desires could work is if he starts his own business and focuses on the fun things while paying others to do the boring stuff. But then again - building a successful business to achieve the luxury of total choice takes a lot of "boring" work beforehand.

I confess that I have trouble seeing the logic in wanting to work for someone for free. Maybe as a short-term learning thing if a temporary position can be structured that way legally.

But, by and large, if you don't care about being paid, why not just work on your own project. Because there's pretty much no such thing as a 100% no-BS position anywhere.

There is a UI problem on GH with forks. (From my limited experience) most profiles that are full of forks the person just uses forks like they would stars. No branches or PRs made. I'd guess, cynically, this is to fill out their profile.

On the other hand a profile of meaningful contributions looks the same on the surface.

I've made a habit of deleting my forks after the PR has been merged upstream to the main repo.

So I'm actually in the position where I do have meaningful contributions to open source projects, but my Github profile doesn't show it (unless you look at my contribution activity).

Without a need for money, I need to rely on this person's ability to be a professional out of the goodness of their heart. Nothing in that post or their previous work says I can rely on that. Frankly nothing in the post or their history shows they have the ability to deliver value that outweights the headache of planning, managing, and integrating them into an existing team knowing how fickle the relationship can be.

It's not similar to a contractor relationship, since there there's at least contracts and deliverables that give some clarity to planning.

As if a craving for money somehow makes professional out of .. whatever.

You completely misunderstand what "professional" means and what the "professional pride" is about.

There is an interesting question about whether they will contribute valuable work, knowing that they probably won't be that professional as you say. When I don't care about quality I can often produce really good results early but that might not be conventional or that maintainable. Maybe it's healthy diversity in approach for a company, better at writing interesting prototypes than a final product?

It seems that if you want to be supremely picky about what you do, and don't care what you get paid, then the obvious answer is to just do your own side-projects, open source them, and have a paypal tip jar where people can send you some money. This pays closer to the $0/hour side than the $100/hour side.

You might also consider working on side projects with an emphasis on them making money, but then I think you'll quickly find that you'll be required to do work that you don't consider fun and interesting, so you'd probably have to give up before it got far enough to become an actual money-making venture. So again, closer to $0/hour.

Or maybe you'd like to do contract work, but again, to fully complete a project for a client is most certainly going to require that you do some work that you don't like, so I don't think anyone is going to pay you for delivering something that's only partially complete, so again, $0/hour.

So Francesco says they refuse to do technical interviews and says their CV and Github are proof enough.

The CV shows experience as a freelance engineer at Apple for a bit, then an engineer for Samsung which they were made redundant from. Their GitHub is 3 projects, a python script, a breakout board and then a beta libary. They argue that's fine though because they'd work for £1/hr, but the real cost of an upfront hire is my time, not money.

The author seems to not understand how key money is for the relationship between manager and employee. I have plenty of employee's who'll work on interesting stuff in their own hours, but I pay them so they stay around and do the boring bits like docs, DR, testing, support, bus-factoring.

I completely understand your point of view and I would think the same if I were you, but that's probably the kind of work I'm trying to avoid.

I only have one life, and I just don't want to be paid to "stay around and do the boring bits", or at least not full-time and in an office. Just as an example, having to stay in the office if there's nothing else to do for the day was absolutely soul-crushing for me. I might be happy doing that kind of work part-time and remotely (almost nobody offers part time work) or I might want to do that later in life.

I read a post about Gumroad here on HN, and that's how I want to work. The way Gitlab does it is also very interesting.

There must be other people who feel and think the same, and the post is just a way to try to reach them.

Just as an example, having to stay in the office if there's nothing else to do for the day was absolutely soul-crushing for me.

That should literally never be the case for a developer though.

You can always be improving the documentation, increasing the test coverage, optimizing for speed/bandwidth/complexity/some other metric you've measured, working out how to measure something, learning new tools or tech that could be applied to a project, working on a spike for some future feature that needs upfront research.

If you see those things as "the boring bits" that you don't want to do then you're not a developer. You're a hacker. You want to hack what you see as the fun stuff rather than developing complete, robust applications that can ship. That's fine, and loads of fun, but no one will pay you to that. You don't get a role like that unless you're some sort of programming savant on a par with the likes of John Carmack or Fabrice Bellard - someone has proven they can invent amazing things by being left to their own devices. Unfortunately, you really need to prove yourself first before you can land a gig like that. If it was easy we'd all have done it.

> Just as an example, having to stay in the office if there's nothing else to do for the day was absolutely soul-crushing for me.

> That should literally never be the case for a developer though.

After 20+ years I've both been in such a position FULL TIME, as have others (eg: Many devs at ServiceNow) - hired on to work on cool things at an old small company and then literally sat around every day with no tasks and no responsibilities while everyone around me either didn't show up or watched TV on their monitors (open-plan btw).

I've seen big company devs do the same, making up busy-work tasks and literally not committing any code for months at a time playing the priority-game of "wait until something more important comes up, someone else will make a workaround" which was surprisingly effective.

The reality that a developer shows up and have nothing to do happens OFTEN in all sorts of organizations - eg last day of sprint, how many times have you pulled in a new multi-day ticket? Developer accountability is at an all-time low when software developers (across many sub-disciplines) can't make accurate estimates, can't meet anyone's estimates anyway, and are at an all-time-high demand. Managers are in a different boat, but same result. Perverse incentives and lack of a consensus (or willpower) on what constitutes value makes for do-nothing-and-get-paid while someone else does the work.

There will always be times when you don't have anything that you've been told to work on.

That is not the same as having nothing to do.

At a certain "senior" level (in terms of attitude rather than job title) you're expected to be a self-starter and think of things to do for yourself. Once you can do that you have no excuse for having nothing to do.

In my experience, it is not like that at all. The not having anything to do simply does not happen. What happens is "not being under pressure". But I was always able to find useful stuff to do, not including learning.

I do learning in work time. Learning could be backup for when there is truly nothing to do, like when git is down or something. But those chances are so rare, that I have to learn while there is stuff to do.

> eg last day of sprint, how many times have you pulled in a new multi-day ticket?

I was in exactly one team where you would wait on this situation. In literally all other teams, it was 100% normal to work on something multiday for next sprint. And that one team was dysfunctional in more then one way.

eh, that's not really the case in a lot of developer jobs these days. A lot of agile/scrum adoption/bastardization has meant that all work done has to be decided by the team and pretty much every piece of work has to be approved by a product manager. This can often lead to some demoralising meetings where you can either lie about the effort/risk/goal or you can give a true value estimate that gets shot down. If you lie, you can end up spending your own free time working on that refactor or documentation etc. For most devs working on a codebase, its not theirs, and they don't determine what has priority.

In reality, for a lot of people, if you start refactoring the codebase while waiting for a new task you are likely to break something and its just not worth the hassle for the developer or the company.

Learning new tools is always great ofc but it can be very hard to find the motivation in such a role, where unless you are a senior developer, you probably won't have much say on adoption, and you will likley just develop a half baked understanding of a new library that you will never get to use in production. Its much better to have some real free time where you can focus on your own projects and learn that way.

So in short, maybe it should never be the case that devs are in that position, but it often is. Especially for devs with less experience

That’s pretty sad and disempowering. For what it’s worth at companies like Facebook it’s completely the opposite. If you aren’t taking any initiative you will not meet expectations at performance review.

I just had a good chuckle at this. I’m skeptical, to say the least. I don’t have direct experience. But I do work at a company that has poached several FAANG employees this past year and whose thoughts...differ from yours.

I can second dkasper's observations -- the PSC cycle is engineered to reward initiative. That said, depending on the team, the practice does not always follow the theory, so it makes sense that the FB employees your company could poach may have been the ones unsatisfied with the way their team rewarded initiative.

Kent Beck became a former Facebook employee because he wasn't in to proving he was moving the needle on Facebook's key metrics. He was only giving world class mentoring to young Facebook engineers and improving the development culture.

Likely you were able to poach them since they didn't thrive in that environment. Or you got them from the more traditional top-down Microsoft, Apple or Amazon.

Or he paid more, had more interesting work, clear path leadership was present, wfh options, family vibe, stock options, less corporate culture, etc..

That sounds like academia, where people are also expected to be constantly innovative on demand and, when the majority just can't pull it off, they invent BS research and produce worthless papers which clog the system.

> if you start refactoring the codebase while waiting for a new task you are likely to break something

The risk of this is in proportion to the lack of test coverage. If you are afraid to refactor, this should be an indication that you need to apply more test coverage, so do that first.

> If you see those things as "the boring bits" that you don't want to do then you're not a developer. You're a hacker.

Well put. Professional software is only a mean for business not an end by itself. I recommend not deriving your satisfaction from code only if you work for a company otherwise you risk to both spoil your hobby and always be unhappy at work.

So what do you derive satisfaction from if you don't enjoy coding for its own sake?

Problem solving

I agree with your overall sentiment, but:

> If you see those things as "the boring bits" that you don't want to do then you're not a developer.

Don't we already have enough gatekeeping in software development? I don't particularly enjoy writing documentation, despite how important I know it to be. That doesn't make me "not a developer." If I were lazy and simply chose not to do the things that bored me (despite their importance), it might make me a bad developer (or more accurately a developer of bad software).

I design and implement software. That makes me a software developer. The pieces of that process that I find boring or exciting are tangentially related at best.

> Don't we already have enough gatekeeping in software development?

No. In fact I hope anyone who's actually worked in the software industry would see that we don't have nearly enough!

Look I'll agree with you about the evils of gatekeeping if we're talking about who gets to call themselves an artist or a writer. Those kinds of distinctions rarely create life or death consequences.

But software can. Not all the time, but certainly in medical, airplane control, banking and financial, and many many more areas.

I wish software would take notes from other engineering fields like structural or architectural. Can you imagine an engineer building a bridge who was like "I don't want to do the boring stuff like stress analysis or geological surveys, I just want to make cool shapes and build them!" Can you imagine trusting your life to a bridge built like that?

Software increasingly runs our world and real software engineers who work on things that really actually matter know they have a responsibility to "do all the boring things" because those things are essential to doing their job right. Hearing about major hacks and exploits every day like SolarWinds, Experian, Facebook that expose our personal information and put us at risk makes me feel like we desperately need more gatekeeping in our field to keep cowboys and hackers from getting the chance to get anywhere near these systems.

I've been in this career for 20 years and the thing I learn more and more is that writing code is perhaps the most trivial aspect of what we do. It's everything around it -- the process, the testing, the security, the collaboration and how teams and organizations operate that are the real challenges to be solved. Anyone can hack together some working code. The hard part is the systems and organizational structures in which it operates.

There are plenty of things to work on in software which are of no real consequence, but as the OP is finding it's pretty difficult to find someone who wants to pay you to work on something which has no value. That's called a hobby not a profession.

As important as those things feel after 20 years you must remember you are hired to write code. As easy as code is to write without none of the other processes are required.

If they wanted someone to just write documentation you wouldn't be hired. A technical writer would be.

If they wanted someone to just test you wouldn't be hired. A QA person would.

Same for whatever processes you create. They would hire a process specialist.

Same for project management. They would hire a pmp certified person first.

Same for business analysis and business requirement gathering.

As a developer there are better people to do all of those jobs at better rates. None of them can code. That's why you are hired. If you couldn't do that than your qa abilities don't matter.

Things have changed over 20 years. Not every company has a qa team or bas or support team. So these tasks end up being picked up by the developer. Often if this slows development teams are created of non-developer specialists. Some developers end up doing very little coding because your job is to go to meetings about projects that never start. But you are still hired to code they just need you on standby.

Anyone cannot hack together something that works. Only a developer can. A hacker would find ways to use an existing system in an unintended ways.

Gatekeeping over this makes you more management than developer.

The tao of programming has a different understanding of what a developer is and isn't


Huh. Plus one to you -- you have meaningfully changed my opinion.

People are better at what they enjoy, but I know very few people who enjoy documentation. I have apent most of my career as what the gp would call a hacker. My redeeming quality is probably my love of testing. I despise formal methodologies and processes, and people who fall in love with tools or languages or language features are hard for me to work with.

I don’t understand that general lack of love for writing documentation. It’s a part I like very much in a project: explaining how it works, why some things are done a certain way, the limitations of the software, the possible configuration options... It’s funto write.

I definitely don't begrudge anyone who likes documentation - but we all have different parts of the dev cycle that we like - some folks love to architect solutions and hate implementation because of the fiddly bits and details - other people dislike the stress of having to come up with overarching approaches and get analysis paralysis but when it comes to splatting out the vision into code it's meditative. Still other folks love to break things and enjoy needling edge cases in unit tests (if you find one of these or are one of these - know their value, they are a hot commodity). Then other folks love the teaching/explaining part that comes with documentation.

I think that there is a way we can improve as an industry to let more people specialize into their niches (which would move us closer to a factory/assembly line sort of setup) but right now most developers are artisans that receive some vague ticket and produce code and everything for it as a result.

I appreciate the validation, as much as I like to see things eork, I also love to break things. Pathological unit tests are fun, but the real low hanging fruit is in finding how two services implemented the same service contract with different assumptions.

If the organization or the product has any amount of complexity, all of those have communication roadblocks. While it’s technically possible to always be learning or practicing something, much of the effort will be wasted by either a focused or a bureaucratic organization. Repeatedly doing work just to give the company an unlikely option on it is counter-productive as it leads to burnout. It’s better to stop work when enough is done for the day or week to stay focused on the efforts that matter.

Probably the best way to apply the “if you have time to lean, you have time to clean” mindset, if it must assert itself, is to actually let developers stuff packages or weed the grounds or something else that can clear their minds. :)

> If you see those things as "the boring bits" that you don't want to do then you're not a developer. You're a hacker.

This point parallels the distinction made in the Software Engineering at Google flamingo book between programming and engineering. Engineering comprises the tools and processes to maintain software over time (this is a rough paraphrase), of which docs, for example, is essential.

So to use their language with your point: this sounds purely like programming and perhaps not engineering.

You may want to rephrase your proposal a bit. Include the part that you are willing to do the boring parts of an otherwise interesting project.

The way it is worded, it would sound to me, as a hiring manager, that you might not finish the work. Because we all know the prototyping / experimentation part of a project is the most challenging and rewarding. Taking it live will involve dealing with the boring parts.

I am not claiming you _are_ such a person, but you might want to make it clear.

> The way it is worded, it would sound to me, as a hiring manager, that you might not finish the work

You read that correctly. The OP said clearly he has no intention to do documentation or testing, meetings, or much of anything other than just write code for about 40 hours and then quit.

I retired close to 7 years ago, and I have a similar set of guidelines for doing part time work. However I have another stipulation which is that if I don't personally know you, I'm not interested, at least for paid work. I've done some volunteer work where I've had introductions from someone I know and that's worked great. And for any given paid job the max I will work is 20 hours/month. That is I might work more than that, but I will only bill that. That allows me the flexibility to put the effort in I think is needed to do what I think is acceptable quality, without imposing my standards on someone who just wants something that will solve a problem immediately in front of them. Good luck!

if you don't care about pay and you want to work on interesting projects, why not start your own?

people typically get jobs because they have bills to pay, not because it's fun. If you are in a position where you don't need to pay the bills with work, then you're in a great position and can have fun all day long - so why not just do that?

If you work on something that also turns out to be marketable then you might even end up with a viable business that you love working on.

> people typically get jobs because they have bills to pay, not because it's fun.

If a position across the street becomes available which allows you to pursue a personal goal you aspire and afford your current lifestyle, would you remain at your current "non-fun" job or give it a shot and apply?

Many people don't just get job because they have bills to pay, they get jobs that they don't like because there is no alternative available to them which meshes with their lives.

To an extent, you could argue "that's personal responsibility, everyone makes tough choices".

Then again, the author tacitly references to the fact they were still obligated to physically attend an office space, even though they could their work remotely. Now expand that to the millions of workers who are forced to make long commutes.

obviously there's such a thing as better or worse jobs, but OP suggested that they were willing to work on whatever, as long as it's fun, for any arbitrary amount of pay.

So OP is in a position where money is not important to them. So why have a job at all? Have a fun or meaningful hobby instead, or start a personal project.

> So why have a job at all?

The author doesn't ask so much for a job, as reflects about something more profound: meaningful, purposeful relationships with others which enables them to manifest their morals, values, identity,...

Interesting work isn't interesting for the sake of spending 8+ hours a day "doing" something. It only becomes interesting when it has an impact on the world which one feels is meaningful.

For sure, a novelist could write books for no other reason then deriving enjoyment of the sheer act of committing words to paper or a screen. But the vast majority of people feel that the things they do in life truly become meaningful when they are seen, used, enjoyed,... by others.

One could argue that one could do so by volunteering, taking initiative, or starting one's own business. However, the vast majorities of opportunities to enter meaningful professional relationships still involve signing a dotted line and a salary.

> work on interesting projects, why not start your own?

For what it's worth, many people who don't need the paycheck, or don't need a particular paycheck still go to a "real" job just because the scope of what they can do on their own doesn't match what they want to achieve.

People also join projects to learn things that are harder/less efficient to learn on your own.

I'm certainly not saying you can't do an interesting project on your own, just that many people are interested in projects they can't practically do on their own. Some might scratch that itch with an open source project or whatever, but especially if it requires hardware development, it may not be practical for many individuals.

> I read a post about Gumroad here on HN, and that's how I want to work. The way Gitlab does it is also very interesting.

But surely they do a lot of boring work at those companies too, as in all tech companies?

Of course, but if it's part-time and full remote then it doesn't take away most of your day/life and I would have no problem with that. I also do translation work which can be tedious at times but I really enjoy it because I can do it from anywhere and just a few hours per week.

The "needs to be interesting" part is more tied to the "pay what you want" thing.

> Just as an example, having to stay in the office if there's nothing else to do for the day was absolutely soul-crushing for me.

The only times this ever happened to me was while I worked in the gaming industry and I absolutely still had work available - but we had some pretty rough overtime expectations that lead to constant overtime even if a different department was behind.

On principle I would just sit there and relax as best as I could in the office if my team wasn't behind. But, keep in mind, that this was also all unpaid overtime at the employee's expense because thank you EA lobbying and a terrible industry. I occasionally lost money on these evenings since transit would shut down and I'd need to cab home.

Now that I've left the gaming industry I doubt I'll ever be in that position again and I continue to have oodles of work in front of me, though, due to ADD and such - I often have trouble with motivating myself to do the boring bits they are part of the job and go with the good.

There are plenty of people who feel and think the same.

Many people find it very difficult to understand that money is not always a motivator. This is a particularly difficult concept for managers to deal with.

If an employee is not motivated by additional remuneration, or in the case where they do not require an income, the relationship between employee and employer is fundamentally different.

> that's probably the kind of work I'm trying to avoid.

The boring bits _are_ part of the job.

> I only have one life, and I just don't want to be paid to "stay around and do the boring bits", or at least not full-time and in an office.

The part about "in an office" is a fair goal, but if you want to avoid docs/tests/support/refactoring work, don't do this job. Writing code is just one part of it, any way you take it, and avoiding the rest is cutting corners. Even our consultants have to write tests and update docs.

I created a part-time jobs board, ParttimeCareers (https://parttime.careers). I collect remote and part-time jobs (mostly engineering jobs, but sometimes marketing jobs).

Yeah, I can see where you are coming from. Some people want to look for part-time jobs because they want to spend more time with their passions, kids, parents, or friends.

I have no problem whatsoever with staying around and doing the boring bits. But if those are exclusively the job, that’s when I take issue.

Just look for part time positions. You can also try to make your own by applying for full time jobs and then springing the part time thing on them at the salary negotiation phase. Yeah, some will balk, but make a cogent argument about how working less hours means your performance per hour should be higher. Which is easily supported by current research. Provide citations if you want. It's sufficiently hard to find good developers, that if you're good enough you can get jobs like this.

I've been working part time, fully remote last year and it was wonderful. I don't think I'd go back to full time work.

After achieving enough trust with the company, I negotiated working alternating weeks. Having a 9 day weekend every 5 work days is incredible. Yeah, I didn't make much money, but I spend that time on my startup, so maybe it will pay off one day. Either way it is a lot more fun!

> and I just don’t want to be paid to “stay around and do the boring bits”

I’m a little ADD, so my most hated work is paperwork and administrivia. Nevertheless, I recognize that it is sometimes necessary (documentation, performance evals, collecting metrics, etc.) and I just get my favorite coffee and suck it up (the work, but also the coffee).

Programmers have arguably the least boring jobs in the world (we can literally automate all the most boring bits except for certain types of paperwork/administrivia) so to hear a developer complain about doing a little bit of boring work smacks of a special brand of entitlement to me. ¯\_(ツ)_/¯

> Just as an example, having to stay in the office if there's nothing else to do for the day was absolutely soul-crushing for me.

This only happens at terrible, un-enlightened companies who are more willing to waste both of your time and pay you a little less than they are to either give you meaningful work or let you go to the beach but stay on-call. Bosses should not be babysitters.

Don't want to stay around to do the boring bits required to make a working product that serves a real world use case? Go into academia! Not making a generalization about academics, it's just that academia is one of the few places you can carve out a place to just work on interesting things and get paid for it.

> having to stay in the office if there's nothing else to do for the day was absolutely soul-crushing for me

Maybe nothing you want to do, but I doubt there was nothing to do. Improving docs, tests, small refactoring to old code to make it more readable are a few examples.

The way you talk about the work culture you want to avoid makes me think you might be interested in "opale" companies and the way they operate. Check "Reinventing Organisations" by Frederic Laloux, there are a couple of software and none software company examples which might be of interest to you.

Have you considered just coming up with your own projects? Set some arbitrary, useless goal that will be an interesting engineering challenge, and have at it. Nobody will force you to write docs or do any other "boring bits". It's a great outlet in my experience.

I think the solution needs to live on both fronts.

IMO the boring bits are boring because there's no time spent to make them not boring.

On all layers of society there are tasks that are under-tooled and under-organized and if you make them worth doing, people will enjoy doing them 24/7.

A lot of people on this thread seem to think that boring work provides job security. Based on your experience it sounds like you have reached a different conclusion. I believe you have the right intuition, that you find valuable work interesting.

You’ll keep doing the “interesting work” until it all turns into “Boring work”, just a matter of time

I think you'd really like Jason Fried's writing. You can find some short posts [here](https://m.signalvnoise.com/author/jason-fried/), but his book It doesn't have to be crazy at work is really great too.

Their GitHub profile has more than 3 projects - you might have only looked at the pinned ones.

But overall, I somewhat agree with Francesco. I used to work at a large corporation where majority of the work was minor config changes and rolling out deployments for handsome pay (somewhat KTLO work). I left because I wasn't growing my career. As companies get bigger the money gets bigger as well but the interesting work gets much smaller. At the end of the day, once you have a solid product in place you need a lot more people to just keep it running vs. work on some very interesting technical work. I think applied research is the best way to go for very interesting technical work but I think the bar is pretty high for that.

But if the work becomes smaller, and they pay bigger, doesn't that mean you now have more time on your hands and more financial security to do something that piques your interest? I understand that one would like to switch from a boring but well paid job, in order to grow their career, but I feel this is for people who need to be told what to do. If you're not that type of person, you have so many opportunities for growth: study a new technology, join an open source project, identify a way to optimize/improve a process at your current boring job and convince management to do it... If you have the initiative, you can create the opportunities that you seek. But if you truly are bored of your current job, the people you work with, etc etc then yeah, there's no point staying even if the pay is great (reminds me of Tony Hsieh's Vesting in Peace moment he described in his book, or his job at Oracle)

[Disclaimer: by using "you" I am not addressing you personally]

> But if the work becomes smaller, and they pay bigger, doesn't that mean you now have more time on your hands and more financial security to do something that piques your interest?

I actually used to think similarly. I might have worded it badly but when I mean the work becomes smaller I am talking about scope and impact - not necessarily the effort required. The example I can give is what I described above: config changes. At a high level it sounds pretty simple but when you delve deeper into how your company/team works with such technologies then there are many barriers in place which hinder you from getting work done efficiently. And processes are slow. In my old team it used to take ~a month to deploy our software world-wide.

You are correct about financial security. At least for me, I am not comfortable enough taking a risk to start something on my own or make a big career change.

I think the overall goal is that you SHOULD be told what to do - up to a certain extent. I am a software engineer so an example for me would sound like "design me a system that does this" or "a customer is asking for this feature request" and that's it. Everything else can and should be left upon the engineers to figure out. Good engineers will design a good system with respect to time for delivery and feature request compatibility.

> But if the work becomes smaller, and they pay bigger, doesn't that mean you now have more time on your hands and more financial security to do something that piques your interest?

Depends on the environment I suppose. If its a classic but-in-seat, locked down, corporate environment, you're probably still constrained for a similar amount of time.

KTLO = "keep the lights on"

Basically just barebones maintenance to keep a product running.

> They argue that's fine though because they'd work for £1/hr, but the real cost of an upfront hire is my time, not money.

Well if it's freelance work there are situations where the upfront time cost is not massive, especially if it's a task with a limited scope. I know this because I hire freelancers.

But yea, I don't have a bag of small-scope, interesting and meaningful tasks lying around...

That depends on your job title and where it falls on the explore-exploit spectrum.

If your job is to keep the gold mine running all your underlings are working on the mine. If they go do something else its a waste of your time and resources.

If your job is to explore the jungle for new mines, then the story is very different. Its more about finding as many curious cheap chimps as you can and sending them out in every direction. In such cases imaginative managers use all the chimps they can find.

I'd also add that interesting or meaningful work itself is a scarce resource. One has to work on finding such work, instead of waiting for someone to give that work. One also has to compete for such work. Salary is a small factor in the equation. Indeed, salary sometimes is a signal in this case instead of a barrier. For a meaningful project, free is probably more expensive than an above-market pay.

"but the real cost of an upfront hire is my time, not money"

The most arduous hiring processes are often little more than an illusion of selection, yielding a process that is more the rolling of dice. Most hiring processes hire based upon interview skills that have extraordinarily little correlation with job performance.

Google has such a famous interview process that everyone tries to clone it. For that they get employees with an average tenure of 3.2 years, made worse that internal project-to-project migration is endemic. They have a tiny core of institutional knowledge, and then a passing army of travelers.

This industry would be far more robust if it hired quickly and fired fast, because the only way you know how someone will do in the role/team/org is by actually having them in the role/team/org. Everything else is just loose proxies that do little. Iterate through people and just punt out the ones that don't work. That shouldn't be a big deal.

Interviews aren't the only cost of hiring. Onboarding is very expensive for knowledge workers.

Onboarding is expensive at dysfunctional organizations. Further, the reality that churn is high among better employees [1] offsets the concern.

But regardless, going through an extensive vetting process is an illusion. It has extraordinarily little correlation with actual work fit or productivity, but the more "rigorous" the process, the more likely you are to stick with a poor fit.

[1] - low performers will hang around forever. The fundamental of the hire slow/fire slow reality is that eventually every organization is 80% dead weight. If you want to avoid onboarding costs (versus dealing with the issues that make onboarding expensive, which is almost always institutional liabilities), hire the worst candidates and they'll be with you forever.

perfectly said +1

> This industry would be far more robust if it hired quickly and fired fast

Agreed 100%. Maybe the fail fast movements in the SDLC, devops, marketing, and product management will start reaching into HR.

Your comment reminds me of https://dilbert.com/strip/2016-08-07


I didn’t even know Apple or any of the other FAANG’s hired freelancers.

All big corporations hire consultants when they can't hire (freeze or fast enough) but need specialized skills or extra hands.

Quite a few "AI" companies hire their "AI" via intermediaries like Lionbridge and Appen heh

The ATX breakout board looks great, thanks for pointing it out! I think that's a good example of an interesting/fulfilling project, since those generally don't exist and the author talks about how it was a direct request from regular people, not some corporate directive.

Don't hire a developer if you want a tester or a support agent or a document writer. Developers cost so much more why not target your task to an expert in that area?

This is interesting!

My own anecdote: when I graduated from college I had zero experience aside from one internship at a small noname company. No one would hire me. I started reaching out to local companies big and small saying I would work for free if they'd use me. Not just programming jobs, but also general IT or even helpdesk jobs - anything remotely computer related. None took me up on my offer. I suppose they saw me as more of a liability than an asset, or that onboarding costs still wouldn't be worth having free labor. It was an interesting eyeopener.

But since you're experienced, your story is different from mine.

Honestly if someone wanted to work for me for free I'd think it's a scam of some sort so wouldn't touch the offer

Sort of a "hmm.. why is this person unhireable elsewhere.. what do those companies know that I don't?" combined with a concern of "this guy's gonna clean out the office when we go home"

Yeah, "i'll work for free" sounds an awful lot like, "you'll pay me with a pound of flesh."

An engineer needs to be capable of earning their keep. Even if they are a novice.

This might sound crazy but free may be worse than offering to charge. "Free" is saying my work offers no value and may even cost more through your time.

I did something like this in the mid-1990s (looking for Unix sysadmin work - or something similar) and then again about four years ago (programming work).

Both times it worked, although I had to cast a wide net and wait a little bit. Both were very, very small underfunded companies. I didn't say I'd work for free, but said I was working for the experience and job recommendation more than the money.

Honestly for the second one it was more about the recommendation, of having something to put on my resume other than my own S-corp and what have you. I could get most of the small scale experience myself (although they pushed me into NoSQL, GCP/EC2 and other things I wouldn't have ventured into - and turning mockups into code too). I was very up front with them too - I promised them I would do cheap work for them for a month and would then be open to offers, and if someone wanted to hire me for six figures I would probably take it. Oddly enough at both companies (1996 and the more recent one) I spent about 18 months working for the company before being hired by a company actually willing to pay.

In the recent situation, I also was fixated on a niche which made things a little more difficult for me initially, although now I am better off it took a little longer to get going in terms of getting paid. Small tech companies are generally looking for people who known HTML, CSS, Javascript and web frameworks like React. If you look like, without needing that much help, you can do tickets/stories to implement features on a web site that uses React, and can pass the standard interview gauntlet for that type of job, I think you will find a job fairly quickly.

"I would do anything" moves quickly to the bottom of the stack. In there I see (maybe wrongly, but when hiring first impression matters) no motivation. I look for people passionate about the work, who have skills and interest on using those. But help desk or programming require very different skills and are quite broad.

I'm not sure if this is still the case, but at least back then (10+ years ago), quite a few people working helpdesk and IT (system admin, network admin, etc.) were CS majors. Or at least it seemed so from my own network. CS was seen as the gateway degree to any kind of computer related career, not just SWE. Are things different now?

I am actually not a CS major - I'm an information systems major. Funny enough, another IS major friend and I ended up as SWEs (him at a FAANG at that), while a whole bunch of CS major friends are working in IT as system or network admins or helpdesk managers.

Such roles still exist and a bunch of people like it. Instead of sitting in front of their own computer and hacking code and a amazing problems there it's finding problems in an application with communication with a different person. Depending on organisation and level this can be quite technical as well.

But when hiring I look for other skills and other interests depending on the role and a key qualification is interest in the kind of role.

> Are things different now?

For me personally, if I were going to go into some other IT fields tomorrow, I’d skip the expensive ass degree period. A lot of IT feels closer to a modern trade than anything.

A lot of jobs require a degree just to get past the HR filter though. In fact, I distinctly remember seeing a even a lot of helpdesk jobs requiring "degree in computer science or related technical major". Again, this is 10 years ago, not sure what the landscape is like today.

Minimum wage makes it illegal to bring you on for zero pay just to get experience.

Tell that to the gaming industry. There are enough people looking to get a foot in the door, and enough companies looking to turn the other way.

I don't know what the limitations are but unpaid internships are not uncommon in certain industries.

There are rules under federal law: https://www.dol.gov/agencies/whd/fact-sheets/71-flsa-interns...

Basically an internship has to benefit the intern and not the employer. It's akin to taking a class.

Any HR rep looking at these standards would not permit someone to come on for free in these circumstances at the risk of being penalized for violating federal labor law.

it’s not that free labor isn’t worth it, it’s that it’s a lemons problem. that is, (the signaling indicates) uncertainty is high, which is what makes it expensive (or if lucky, a fantastic deal). most people are rather risk-averse and therefore prefer safe choices, with the commensurate relinquishment of potential greater gains (and greater losses).

the lesson should be to value your labor correctly, as large deviations in perceptions of value mean that transactions won’t happen. a more astute approach would be to communicate your (accurate) understanding of your own value and your willingness to negotiate alternate dimensions of value in exchange, like getting experience faster or doing more interesting work in exchange for less money.

tl;dr: establish a common understanding of value, then negotiate.

Of course this was communicated clearly - that the reason I would be willing to work for no pay was because my objective was to gain experience. I also mentioned that if they considered me valuable and worthwhile enough, to feel free to take me on as a "real" employee down the road.

that's not clear at all. you essentially keep say you'd "work for free", rather than "my work is worth x, let's exchange". the latter puts you on equal footing psychologically, while the former puts you at a distinct disadvantage.

No, I mean back when I was actually doing this. The communications to the companies I would reach out. Not my posting HN.

It would not be legal for them to do that.

I wish you the best of luck. I can relate to where you're at.

One thing that I have been doing, my entire adult life, is shipping product. A lot of "ship" is not fun. There's all kinds of boring stuff, like good design (as opposed to "just enough design to get started"), good coding (as in "code I'll understand when I come back to refactor in three months"), good quality (as opposed to "Who cares? I'll be out of here, before they run out of integer space"), good testing (as opposed to "I'll write a few unit tests that show it handles low-hanging-fruit problems"), accessibility, localization, aesthetic design, supporting documentation for users, administrators and developers, etc. You get the drift. Lots of "not-fun" stuff, there.

For me, I've always enjoyed "finishing" projects, and that means shipping them, so users get their grubby little paws on my work, and start abusing it (and, sometimes, me).

I'm taking on a CTO role (I've actually been doing it for months, but we're formalizing it). I was asked to write my own job description. I used words like "Accountable" and "Responsible" a lot. I got used to that, working for a Japanese corporation for 27 years.

Not fun. But I get to run the whole show, and ship. That's my idea of fun.

Oh, and I totally relate to the thing about LeetCode interviews and whatnot. I have tens of thousands of lines of code, ship-ready projects that people can clone, build, and run, dozens of articles, etc. It has been my experience that these are totally ignored; which I consider...not sane.

I have found the greatest pleasure in writing software that helps people help people. These organizations don't usually get "top-shelf" talent, so they tend to have a great need.

Again, good luck.

Why not just working on some open source projects? If you do some interesting helpful work, some people might even sponsor you.

I'm not primarily a financially motivated person. And I would prefer to spend my time doing something interesting. But in my experience, taking on some one else's projects that are interesting but not well paid has always gone badly.

Positions are usually low paid for one of two reasons: either there isn't a budget for it, or there is but they're being cheap and cutting corners. If there isn't a budget, that's a sign of a failing organization or a bad startup idea, so probably not a job you should take. If they're being cheap, that's a sign that they don't respect or value the people doing the work, which is a huge red flag.

I've taken jobs that were essentially volunteer work because I got to work on projects that were interesting to me. I've also taken jobs that weren't that interesting to me which paid generously. In the end, much of my volunteer work wasn't valued, and seen as disposable. The more highly paid work never got interesting, but having a decent amount of money took off a lot of the financial stress and ultimately made me happier and enabled me to spend more of my free time on things that interested me.

At this point, no matter how interesting, there are only two people I would do underpaid work for: myself, and my grandmother.

What about PHP or Java has anything to do with not "programming at a more advanced level"?

These are general-purpose programming languages. Due to their design, some patterns/paradigms might seem more natural to implement, but you can build anything you want with them.

For an experienced programmer eschewing conventions with this "resume", I am surprised by this comment.

>For an experienced programmer eschewing conventions with this "resume", I am surprised by this comment.

They only have about a year of full-time engineering experience, so they might not recognize this yet. (Not trying to talk him down; plenty of people without much experience still do valuable work, but it's only natural to have blind spots.)

It kinda makes him sound like a spoiled junior who only touched the 'hip' stuff and is disgusted by a sign of stability. I remember being in that place as well.

This attitude comes across as a little arrogant, and I'm not sure whether it's warranted without a host of achievements to back it up. Nevertheless, I hope the best for the author, who seems to know what they want.

I think they would have better success by actively seeking what they want, though, rather than expecting it to turn up at their doorstep.

imho this post is pretty much going for what you want! :)

rattle your network until you find a tenured professor who has interesting-to-you grants, and talk them into letting you join the lab as a visiting researcher.

if you do it right they’ll be overjoyed to have technical staff who aren’t degree candidates and you’ll get something tasty to intellectually munch on.

My lab actually did this for a bit. They hired a programmer who was retired but bored and just wanted to do something for far less than market rate. She was great and got a lot done but two problems:

1) It took my boss significant effort keeping her busy with things to do: explaining the problems we needed solved, etc. is non-trivial

2) Since she was working for so little, she could basically dictate what she was or wasn't doing. The very fact that she wasn't on a real salary meant it was actually harder to work with her in some sense.

He did not graduate so he is not eligible for any work as a researcher inside any eu university.

This isn't correct. You can work as a researcher without a degree, certainly in the UK. A general example would be an associate professor at a business school with extensive career experience who might contribute to some papers. An anecdotal example is myself; I don't have a bachelors degree but during my masters degree I had some summer research work. I ended up not finishing the masters degree but did chat about the possibility of going back to do a part-time PhD.

I don't understand.

In UK you can be associate professor without a degree?

Then you talk about your time "during a master degree" but you say you had not a bachelors... How can you do a master without a bachelors?

Now I understand why other members of academia, even when UK was part of EU, treated it as a special case for research positions. Btw not judging, just saying it is totally different of what I expected.

> In UK you can be associate professor without a degree?

Yes, in rare occasions! More frequently without say a higher degree. One that springs to mind is the current Professor of Poetry at Oxford University who read classics for their undergrad but with no further education. https://en.wikipedia.org/wiki/Alice_Oswald

I know there are other examples but I'd need to google a bit to find them. Notable people who got a PhD without a Bachelors or Masters in the US include Wolfram, so it's not just in the UK where rules get a little bent.

> How can you do a master without a bachelors?

Experience in industry counts if its highly related. I was offered or interviewed for postgraduate courses at the University of Leeds, Oxford University, University of Leicester, and a few others. All in Software Engineering and I eventually accepted a part-time position on an MSc in Computer Science. A bit of rigmarole but not that much - I started the course at 25 with 6 years experience in tech. After some pestering I was able to help with some lecturers papers which led to the whole PhD discussion but dropped the MSc because it wasn't as rigorous as I hoped it'd be (I'm interested in the foundations of computer science and this was more applied). If it helps I've been to doctoral summer schools in both the EU and US without any credentials either!

Maybe the UK is the only place with such ways, I emailed Stanford a while back (I'm moving there this Summer, my partners a postdoc, and wanted to try audit some of their postgraduate CS courses) and got shot down pretty quickly!

I understand degrees being a requirement for medicine or hard engineering, but for research and topics of the mind it's just an expensive, multi-year hazing ritual into academia.

Plenty of good people go straight into industry after getting their BCs. (or avoid degrees entirely) because of this.

Couldn't he be hired as an engineer or technical staff?

I don´t know for all the eu nations, but for those that I know staff researcher positions still require degrees (and there is a lot of competition to get those because they are even more limited in number than tenure track positions, just with far less requirements)

In mine in particular everyone has at least a Master Degree with some publications. One of two even got a PHD.

A couple notes:

1) You needn't necessarily restrict this to tenured professors. Indeed, plenty of new tenure-track professors have both the need and startup resources to potentially hire you if you're likely to boost their group's productivity.

2) It's hard to fund people with grant money who weren't written into the grant in the first place. So while grants might be interesting as an indicator of interest, they don't necessarily ensure you'll be hirable. Which means either patience, or hoping they have a small slush fund somewhere - which is more likely for a tenured professor, but not exclusively so.

Yea i feel like a job in research would be best fit, but that probably also requires a certain level of graduation.

It doesn't, necessarily.

I've hired people to work helping support academic projects without ever looking at what their degree is in.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact