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.
Ask HN: Are you working on interesting technical problems?
11–20 of 441 posts
Re: Ask HN: Are you working on interesting technical problems?
#12I 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!
Re: Ask HN: Are you working on interesting technical problems?
#13Have 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.
Re: Ask HN: Are you working on interesting technical problems?
#14For 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
Re: Ask HN: Are you working on interesting technical problems?
#15I 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 li…
90% would be fine. The problem is that it's 100%.
Re: Ask HN: Are you working on interesting technical problems?
#16If 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...
Re: Ask HN: Are you working on interesting technical problems?
#17As 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.
Re: Ask HN: Are you working on interesting technical problems?
#18"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...
Re: Ask HN: Are you working on interesting technical problems?
#19I 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
Re: Ask HN: Are you working on interesting technical problems?
#20If 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.