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
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 recently user-tested a job posting for a high-meaning job.  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.
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.
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'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.
"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.
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.
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.
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.
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.
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.
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.
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 .
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.
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.
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.
- 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.
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.
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.
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.
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.
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.
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.
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?
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.
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
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 ?
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.
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!
> 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.
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.
[...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.
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!
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.
This reminds me of the advice that one needs to cultivate their passion rather than expect to stumble upon it.
I think the first time I read about this idea was in this article by Mark Manson: https://markmanson.net/question
(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.)
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.
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’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.
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).
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.
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 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).
> 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.
I generally don’t have this issue in my actual 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.
When I get stuck on projects that are not so meaningful to me, I reduce scope.
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!
If you have a broad interest there's like a million different ways to pivot and branch off to learn different things.
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.
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.
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. ¯\_(ツ)_/¯
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.
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'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.
It doesn't mean that you hired the wrong people. Just that your needs are changing.
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.
There's nothing worse than being stuck in a job where you're watch the clock, waiting for it to strike 5 PM.
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.
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.
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.
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.
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.
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.
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.
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.
>> 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.
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.
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.
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.
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.
On the other hand a profile of meaningful contributions looks the same on the surface.
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).
It's not similar to a contractor relationship, since there there's at least contracts and deliverables that give some clarity to planning.
You completely misunderstand what "professional" means and what the "professional pride" is about.
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.
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 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.
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.
> 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.
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.
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.
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
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.
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.
> 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.
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.
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
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.
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. :)
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.
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.
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.
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.
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.
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.
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.
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.
But surely they do a lot of boring work at those companies too, as in all tech companies?
The "needs to be interesting" part is more tied to the "pay what you want" thing.
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.
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.
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.
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'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!
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.
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.
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.
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.
[Disclaimer: by using "you" I am not addressing you personally]
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.
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.
Basically just barebones maintenance to keep a product running.
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...
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.
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.
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.
 - 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.
Agreed 100%. Maybe the fail fast movements in the SDLC, devops, marketing, and product management will start reaching into HR.
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.
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"
An engineer needs to be capable of earning their keep. Even if they are a novice.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
I think they would have better success by actively seeking what they want, though, rather than expecting it to turn up at their doorstep.
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.
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.
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.
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!
Plenty of good people go straight into industry after getting their BCs. (or avoid degrees entirely) because of this.
In mine in particular everyone has at least a Master Degree with some publications. One of two even got a PHD.
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.
I've hired people to work helping support academic projects without ever looking at what their degree is in.