Ask HN: Are you working on interesting technical problems?

Yes. But I understand you, and I agree. I was there. I quit my job in a big tech company a few months ago so I could work on more interesting problems. I started a company a few months, and it's been hard - exactly what I was hoping for.

There are interesting problems (technical and business) in boring businesses. If you want to work on interesting technical problems you probably need to excel at a technical company. At an enterprise you are likely to find "interesting" business problems which you should really endeavor to solve in the simplest most fault tolerant manner. If you can work out which parts of CS interests you maybe you could find a problem to apply that to or research in depth.

Hmm, maybe. I work in Natural Language Processing for medicine, and there are many interesting challenges ... a lot of them still academic even. But the biggest thing I'm worrying about these days are more business oriented. Machine Learning, and Natural Language Processing in particular, is nowhere near advanced or accurate enough to fully automate things. So most of my thinking goes into things like "given the limited abilities and limited data, how can we still make something that is useful". That's both a business and a UI/UX problem...which suck up a lot of brain cycles for me. Up to the point that I've become somewhat cynical and wish I was doing CRUD work instead ... since all the hype around NLP usually amounts to saying "yeah no, that's not really how it works, and you'll [the customer] be disappointed if we actually did that". The hype train is both a blessing and a curse

Completely. After 10 years it's still just data in, data out and the only real challenge lies in deciphering business requirements.

Whenever I have spare time I'm trying to build a solution like Walk Score for where I live, where such a thing isn't available. Hopefully something will come of that.

No, I'm only working on a boring problem. But since I can't say I've got a real computer science degree, I find it hard enough already.

My day-to-day is mostly CRUDs, yes. However, the consultancy-company I work for has various interest-groups. I'm leading one for "Algorithms". We meet (on company time) and do various things related to that theme. Workshops, learn stuff etc. I think it's a smart way to keep us motivated, while also creating knowledgeable consultants.

Some recent activites: 1. Workshop on evolutionary algorithms I made https://matsemann.github.io/walkingea/ 2. Workshop on max flow algorithms people worked on: https://github.com/Matsemann/maxflow-workshop 3. We played elevator saga 4. Lightning-talk bonanza where people prepared small talks related to hard problems / CS theory. 5. This week programming LEGO robots

Academics: just take an interesting problem that you can generate potential solutions for, but if you can't, just pick the next problem.

Business: here is a continuous stream of problems, most of them are boring, some of them are hard, but you have to solve them all regardless.

What would be interesting for you? What would you like to do?

Does your employment contract allow you to do this in your own time?

For me, I'm more interested in a particular domain, rather than the technologies around it. So, for example, I like marine biology, so the projects (and work) all revolve around that. You might like distributed databases, so why not work around that. Find what interests you, and move towards that direction. Some people have contracts that say that their employers owns all their work even when they are not at work, and some say they cannot do open source work, so this could be a constraint.

Absolutely, yes. Using your CS skills to write CRUD apps is the path of least resistance to create economic value. Where I live (Johannesburg), the demand for CRUD apps is so high that no single firm or group of firms can absorb it all. You can happily create a thriving software development business in Johannesburg without worrying about competition (maintaining standards and hiring well is a different story).

The most exciting thing at my old job was this DFS I had to do once.

That said, there are very interesting tech jobs out there - such as scaling boring old CRUD apps. The high frequency trading space also has many interesting problems. Imagine working on a system where you start to care about nanosecond optimizations. I interviewed (and failed at it, lol) at Optiver [0]. You should check them out.

[0] https://www.optiver.com/na/en/

Welcome to the real world:-) In my view, that's where interesting side projects come in. Either "side of desk" projects at your company, if you're fortunate enough to work for one which encourages or at least recognises innovation and/or has some form of incentive mechanism, e.g. management who actually know something about technology and who might actually be impressed by your enthusiasm and extra-curricular activities and consider you for promotion or a bonus or whatever as a result. Or if you really are in a dead end job with none of that, then side projects in your own time that keep you interested in technology and your skills current and which might even help you get your next job.

I think with time you may find such drudgery is present in every field. Ninety percent of any kind of work we do is gluing together components and solving boring business needs. It's part of the reason I think we engineers love side projects so much -- they're easy to start up, and you can try out academically interesting things (obscure programming languages, cool algorithms, etc.) without caring about the bottom line.

Side projects are good for your brain and in the long-term good for your career (lest you stagnate with old technologies). I recommend having this outlet. On the plus side, having a somewhat interesting job + really interesting side projects gives you both good money and intellectual freedom.

If you want to solely focus on interesting technical problems, I'd recommend working in a research lab or going to academia. On the downside, you may lose that nice paycheck, but your curiosity will remain forever piqued!

Have been in that boat on several occasions. Eventually escaped to do a PhD and research. Intellectually very challenging and eventually satisfying ... but the money was dreadful. So I'm back in the biz end of IT, boring but well paid.

I think we need to look at how any given company makes revenue. In most cases, it isn't innovation, just same ol' day by day. The only viable escape seems to be to run away with a startup (circus). They can be real fun, but many do flame out and crash. Hard to pick the winners with a technical viewpoint. Again, it comes back to business fundamentals and investor vicissitudes.

For me that's where side projects come in. I'm working on Maths teaching software [1], which allows me to combine my teaching experience (figuring out what feedback to give as students work through problems and when) with my (limited) technical experience (which admittedly has been 80% gluing libraries together!).

The day job still pays the bills but finding something that interests me personally while also offering potential future rewards is what keeps me going.

[1] https://blutick.co.uk/demo - alpha stage right now

If you're bored you're doing it right. Read 'Programming sucks! Or at least, it ought to'[0]

[0] https://thedailywtf.com/articles/Programming-Sucks!-Or-At-Le...

As a freelancer, occasionally I am hired specifically to solve an interesting or novel technical problem a particular organization is not staffed for.

For "normal" contracts, I'm usually leveraging open sourced libraries when possible, and implementing things in the most uncontroversial way possible. My main goal is to leave the customer with a product which does the job, performs well, and can be easily understood by the next developer to pick it up. In these type of projects, my main outlet for creativity is in custom tooling and workflow automation, not anything user-facing.

Other than that, I solve lots of interesting technical problems in my free time.

"figuring out business requirements"

Have you tried looking here for inspiration? The challenges here may be less technical, but that doesn't necessarily make them less interesting...

I am... I'm working on Gorgonia[0]. My goal this year is to provide a good alternative to Tensorflow and PyTorch. At the same time I'm working on several side projects that I believe will cause the fruition of an AGI.

I'm lucky in the sense that I get to work on things that uses Gorgonia at work (though I don't actually work on Gorgonia itself proper). Took a helluva long time to get here though. And very many failures

[0] - https://github.com/gorgonia/gorgonia

If there's a bottleneck anywhere in what you're working on, that's the most likely place for you to apply CS. But it's a tricky business; there's a risk benefit trade-off.

Writing complex code to solve a gnarly problem is often the wrong path, because it's harder for coworkers to understand the code, and harder for future maintainers to keep it correct. Thus it's often better to encapsulate the hard problem in a nice interface, and possibly release it as a separate library.

That's where most of those libraries you're gluing together come from. A tough bit of code that needed writing but also encapsulation.

A tougher problem than most CS problems you'll find while writing CRUD apps is getting architecture right, so that adding new features isn't an uphill struggle and doesn't involve piles of boilerplate. Getting the aesthetics right, making the code clear so that anyone can maintain it - this requires experience and the mastery that comes from it pays off in the longer term, because you can more easily leverage other people's efforts too.

If you can't find solace in mastering software design, you're better off moving away from CRUD apps and move to a developer of tools. Tooling, whether it's compilers, OSes, databases, whatever - has more interesting and deep technical challenges. Watch out though: tooling often doesn't pay particularly well because developers enjoy making tools themselves. They'll prefer to build their own shoddy hammer 9 times out of 10, precisely because they're in the same boat as you right now: they don't feel challenged.

You should dabble in gamedevelopment, lots of room for innovation. Often you'll end up implementing some custom algorithm or solution where there were no previous library X that solved your exact problem. Sure, there are obviously lots of engines, algorithms, libs, standards here too... but I think it's one of the areas where you often have to come up with some new creative solution. At least, most of it is not CRUD ;-)

My work is also similar to OP's: CRUD and figuring out business requirement (so called 'domain driven design'). It's kinda boring but the pay is good and there is almost no pressure. Some of my better coworkers are leaving for big data/ai/next big things startups, so to keep my mind from getting too cruddy I am doing the following: - Keep learning, reading old good algorithm books, trying new techs and skills to improve myself. My employer actually encourage this. - Sharing what I have learned with my coworkers so I can have better understanding and also help my coworkers too (sometimes). This is also encouraged by my employer. - Foster adoption of those techniques in company's own project. Even CRUD apps benefit from good type safe functional programming practice, or batching with akka stream etc... - Aside from those I also help my friend with his analytics startup as my Scala skill is useful for that line of work.

All of the above help me with finding a new company in case the current one goes out of business too.

Just submitted my PhD in ML (waiting to defend) and started working as a contractor in an exciting enough arm of a boring enough company.

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.

Nope, it's CRUD and front-ends for me too - which, mind you, comes with its own challenges and whatnot, but it gets sameish.

At the same time, more difficult problems intimidate me on the one hand, and on the other, I feel more difficult problems are more because of bad architecture decisions (urgh, microservices) or some other kind of mental masturbation. That last one is mostly me being cynical and jaded though.

I was in the happy position of finding a job (post being a failed academic) doing stuff at the intersection of architecture and algorithms (high-speed regex implementation) and getting to to this for 11 years straight (2 years as a researcher, 5 years as a startup CTO, 4 years as a Principal Engineer at Intel). Got a decent if not ginormous exit too, which was nice. Also got to IMO change the industry - Hyperscan (github.com/intel/hyperscan) is used in a lot of places.

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.

I somehow managed to push myself towards working on interesting technical problems. ( That of course depends on what you mean by "interesting technical problems" )

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.