Ask HN: Are you working on interesting technical problems?

So far it's all boring CRUD - but there may be interesting problems to solve as our team and product grows. I'm trying to position myself as the guy to tackle these interesting problems by taking a proactive role in planning and project management, without cornering myself as an irreplaceable part of the boring part of the business.

This nice run has come to an end for me and my team and it's made me realize that getting to work on nifty, complex algorithms and do real CS is not the default. To say the least.

I'd like to try to figure out how to do it again: the "algorithms startup" is a fun thing to do. You aren't going to be raking it in as having the 'nice library to do task X' doesn't allow you to capture huge amounts of value relative to the people selling boxen/UI/SAAS/etc. that wraps up your library. But you can work on a decent scale.

I am thinking about blogging about this; generally I've been sticking to tech stuff on branchfree.org so far but having done this successfully once makes me wonder if it could be done again.

My playbook is: 1. Join a product company. If you work in a software house, it will be optimized towards path of least resistance. You need to work at a company that has long-term relationship with the product for it to even have interesting problems. 2. Be joyful about solving boring CRUD stuff. Don't over-engineer, your enjoyment is not the goal. At this point, you need to build trust that you are indeed trying to solve a problem, NOT entertain yourself. ( Be careful about future-proofing. ) 3. Now, at some point, there will be a project that nobody wants to do. It will be a mess, so natural inclination of most people will be to turn it away, run from it or try to ask for better research / drag the initial phase or whatever stalling tactic will be handy.

But, inside that messy, scary project is an interesting technical problem. What you want to do is to volunteer to take care of that mess without any prior experience and with a feeling that you have no idea what you are doing. You will also need to take full ownership of it.

The best solution is to establish a Skunkworks-like setup, where an extremely lean team has low communication overhead and is isolated a bit from the rest of the company.

Benefits of it will be: a) You will gain 3 years of "company experience" in 3 months, so you will be a better candidate for next interesting problem, b) People know that everybody dreads a certain project. Usually, you can make it in half the time everybody else will think it takes. You can coast on the reputation for months and not really do much work once you solve it. Also business is extremely happy since dreadfull projects are worth more than the entire year of mundane work. c) You will push the edge and expectation inside the company. Once these dreadful projects go away, the resources and infrastructure are ready for more sexy projects. You will have the pick at them because you now have a reputation for not-overengineering, delivering and solving technical issues.

But, it is: - scary - unknown - uncomfortable

Of course - as I said, not every organization has those problems and introducing them prematurely where CRUD will suffice will actually hurt you. You need to have product knowledge and understand what business need is solved this way. There will be business/marketing overhead and you cannot avoid that. You need to think about customers needs first and foremost.

This is how I put myself in a position to solve one interesting technical problem after the other at Automattic.

For the first 7 years I worked as a "programmer", ie. writing code, a lot of C++, and of course web stuff. About 6 years ago I (accidentally) became a "data guy". I do a lot of data infra/engineering, a lot of stats and analytics, and lately ML. Also I do a lot of management stuff and hiring.

I'm lucky, this is a pretty sweet time to be working for me. My skills are a perfect match for the work, I'm able to do impactful work and can get paid for it.

I don't really care about interesting technical problems that much, in the sense that I don't want to solve an interesting technical problem just because it's interesting. What matters is having an impact on your users and the business.

I think if you're looking for those types of technical challenges, it's better to contribute to open source code, rather than doing it at the day job. At the day job, you should always choose the method which makes sense to move fast..