[CuriouslyC]

Not necessarily. It is entirely possible to have a job where your role is to figure out elegant solutions to hard problems. If you hire someone ostensibly for that role, and they end up spending most of their time refactoring the code of junior devs, writing tests and tweaking the build process, they have a legitimate grievance and are fully justified in leaving.

On the other hand, if someone got hired on for a typical mid-level developer/engineer position without any promises of a research/advanced engineering focus, they need to man up and do their job.

[lazaroclapp]

> Not necessarily. It is entirely possible to have a job where your role is to figure out elegant solutions to hard problems.

Sure. But often when that's the case your title will say something closer to "Principal Researcher", rather than "Software Developer Engineer".

Don't get me wrong, a good thing about a job in engineering is that figuring elegant solutions to hard problems is a significant part of what you do there. Also, you can definitely optimize for that being a larger part of your time, if you aim for that when choosing where to work.

However, the jobs for which that is the only function you are employed to fill, and where you are expected to delegate maintenance of your elegant solution to someone else, are exceedingly rare. That's why the academic job market in CS is so much harsher (including industry research labs) than the software development job market. And, for the record, research work does end up involving either some amount of grunt work or some amount of management work at every place and level I have seen so far (universities, industry research labs, etc)

[danieltillett]

As a former academic I would say that there is more boring grunt work in academia than industry. Even worse a lot of it is totally pointless activity caused by the university bureaucrats needing to justify their position.

[yeukhon]

> On the other hand, if someone got hired on for a typical mid-level developer/engineer position without any promises of a research/advanced engineering focus, they need to man up and do their job.

I think this is a self-driven promise. Like another commenter said, this is up to your job description. If you work in the research department, you are more likely to do more "innovative" thinking than those who are hired to build a product because your primary job won't be building CEO a search box. "Product" can be interesting or totally banal, whether you are hired to build public-facing application, or internal application.

I say research focus is self-driven because unless you work in an extremely "do what I say or you are fire" environment, normally you can tell your lead or the product team how to build or enhance a feature. If you think your automated testing infrastructure looks broken, offer ideas to folks who are paid to build that part of the infrastructure. Sometimes, overstepping into another team's boundary is actually a good way to tell people you are capable of doing more than implementing a stupid drop down menu. IMO a good software engineer begins with you giving a clear analysis of the problem and providing a clear and competitive solution (pros/cons with other solutions). That's research, that's "leading", that's architectureing. As simple as building a drop-down menu, well, are you tired of writing a whole new menu every single fucking time yet? Well, here is a research, here is an architectural change - make that shit reusable and make your template whatever resuable, convince your colleague your suggestion is better than theirs and that they are idiot this whole time. No not that hash, but along that line.

And most real research job spend a good portion on writing and doing presentation.

Yeah I keep saying implementing a drop-down menu. But why? Because a lot of the tickets will be around enhancing user experience and that can either be very interesting to some, or extremely boring just because.